By Mladen Turk

Fronting Tomcat

One might ask a question Why to put the Web server in front of Tomcat at all? Thanks to the latest advances in Java Virtual Machines (JVM) technology and the Tomcat core itself, the Tomcat standalone is quite comparable with performance to the native web servers. Even when delivering static content it is only 10% slower than recent Apache 2 web servers.
The answer is: scalability.

Tomcat can serve many concurrent users by assigning a separate thread of execution to each concurrent client connection. It can do that nicely but there is a problem when the number of those concurrent connections rise. The time the Operating System will spend on managing those threads will degrade the overall performance. JVM will spend more time managing and switching those threads then doing a real job, serving the requests.

Besides the connectivity there is one more significant problem, and it caused by the applications running on the Tomcat. A typical application will process client data, access the database, do some calculations and present the data back to the client. All that can be a time consuming job that in most cases must be finished inside half a second, to achieve user perception of a working application. Simple math will show that for a 10ms application response time you will be able to serve at most 50 concurrent users, before your users start complaining. So what to do if you need to support more users? The simplest thing is to buy a faster hardware, add more CPU or add more boxes. A two 2-way boxes are usually cheaper then a 4-way one, so adding more boxes is generally a cheaper solution then buying a mainframe.

First thing to ease the load from the Tomcat is to use the Web server for serving static content like images, etc..

Figure 1. Generic configuration

Figure 1. shows the simplest possible configuration scenario. Here the Web server is used to deliver static context while Tomcat only does the real job - serving application. In most cases this is all that you will need. With 4-way box and 10ms application time you'll be capable of serving 200 concurrent users, thus giving 3.5 million hits per day, that is by all means a respectable number.

For that kind of load you generally do not need the Web server in front of Tomcat. But here comes the second reason why to put the Web server in front, and that is creating an DMZ (demilitarized zone). Putting Web server on a computer host inserted as a "neutral zone" between a company's private network and the internet or some other outside public network gives the applications hosted on Tomcat capability to access company private data, while securing the access to other private resources.

Figure 2. Secure generic configuration

Beside having DMZ and secure access to a private network there can be many other factors like the need for the custom authentication for example.

Figure 3. Load balancing configuration

Configuration containing multiple Tomcat application servers needs a load balancer between web server and Tomcat. For Apache 1.3, Apache 2.0 and IIS Web servers you can use Jakarta Tomcat Connector (also known as JK), because it offers both software load balancing and sticky sessions. For the upcoming Apache 2.1/2.2 use the advanced mod_proxy_balancer that is a new module designed and integrated within the Apache httpd core.

Calculating Load

When determining the number of Tomcat servers that you will need to satisfy the client load, the first and major task is determining the Average Application Response Time (hereafter AART). As said before, to satisfy the user experience the application has to respond within half of second. The content received by the client browser usually triggers couple of physical requests to the Web server (e.g. images). The web page usually consists of html and image data, so client issues a series of requests, and the time that all this gets processed and delivered is called AART. To get most out of Tomcat you should limit the number of concurrent requests to 200 per CPU.

So we can come with the simple formula to calculate the maximum number of concurrent connections a physical box can handle:

                              500

Concurrent requests = ( ---------- max 200 ) * Number of CPU's

AART (ms)

The other thing that you must care is the Network throughput between the Web server and Tomcat instances. This introduces a new variable called Average Application Response Size (hereafter AARS), that is the number of bytes of all context on a web page presented to the user. On a standard 100Mbps network card with 8 Bits per Byte, the maximum theoretical throughput is 12.5 MBytes.

                               12500 

Concurrent requests = ---------------

AARS (KBytes)

For a 20KB AARS this will give a theoretical maximum of 625 concurrent requests. You can add more cards or use faster 1Gbps hardware if need to handle more load.

The formulas above will give you rudimentary estimation of the number of Tomcat boxes and CPU's that you will need to handle the desired number of concurrent client requests. If you have to deploy the configuration without having actual hardware, the closest you can get is to measure the AART on a test platform and then compare the hardware vendor Specmarks.

Fronting Tomcat with Apache

If you need to put the Apache in front of Tomcat use the Apache2 with worker MPM. You can use Apache1.3 or Apache2 with prefork MPM for handling simple configurations like shown on the Figure 1. If you need to front several Tomcat boxes and implement load balancing use Apache2 and worker MPM compiled in.

MPM or Multi-Processing Module is Apache2 core feature and it is responsible for binding to network ports on the machine, accepting requests, and dispatching children to handle the requests. MPMs must be chosen during configuration, and compiled into the server. Compilers are capable of optimizing a lot of functions if threads are used, but only if they know that threads are being used. Because some MPMs use threads on Unix and others don't, Apache will always perform better if the MPM is chosen at configuration time and built into Apache.

Worker MPM offers a higher scalability compared to a standard prefork mechanism where each client connection creates a separate Apache process. It combines the best from two worlds, having a set of child processes each having a set of separate threads. There are sites that are running 10K+ concurrent connections using this technology.

Connecting to Tomcat

In a simplest scenario when you need to connect to single Tomcat instance you can use mod_proxy that comes as a part of every Apache distribution. However, using the mod_jk connector will provide approximately double the performance. There are several reasons for that and the major is that mod_jk manages a persistent connection pool to the Tomcat, thus avoiding opening and closing connections to Tomcat for each request. The other reason is that mod_jk uses a custom protocol named AJP an by that avoids assembling and disassembling header parameters for each request that are already processed on the Web server. You can find more details about AJP protocol on the Jakarta Tomcat connectors site.

For those reasons you can use mod_proxy only for the low load sites or for the testing purposes. From now on I'll focus on mod_jk for fronting Tomcat with Apache, because it offers better performance and scalability.

One of the major design parameters when fronting Tomcat with Apache or any other Web server is to synchronize the maximum number of concurrent connections. Developers often leave default configuration values from both Apache and Tomcat, and are faced with spurious error messages in their log files. The reason for that is very simple. Tomcat and Apache can each accept only a predefined number of connections. If those two configuration parameters differs, usually with Tomcat having lower configured number of connections, you will be faced with the sporadic connection errors. If the load gets even higher, your users will start receiving HTTP 500 server errors even if your hardware is capable of dealing with the load.

Determining the number of maximum of connections to the Tomcat in case of Apache web server depends on the MPM used.

On the Tomcat side the configuration parameter that limits the number of allowed concurrent requests is maxProcessors with default value of 20. This number needs to be equal to the MPM configuration parameter.

Load balancing

Load balancing is one of the ways to increase the number of concurrent client connections to the application server. There are two types of load balancers that you can use. The first one is hardware load balancer and the second one is software load balancer. If you are using load balancing hardware, instead of a mod_jk or proxy, it must support a compatible passive or active cookie persistence mechanism, and SSL persistence.

Mod_jk has an integrated virtual load balancer worker that can contain any number of physical workers or particular physical nodes. Each of the nodes can have its own balance factor or the worker's quota or lbfactor. Lbfactor is how much we expect this worker to work, or the workers's work quota. This parameter is usually dependent on the hardware topology itself, and it offers to create a cluster with different hardware node configurations. Each lbfactor is compared to all other lbfactors in the cluster and its relationship gives the actual load. If the lbfactors are equal the workers load will be equal as well (e.g. 1-1, 2-2, 50-50, etc...). If first node has lbfactor 2 while second has lbfactor 1, than the first node will receive two times more requests than second one. This asymmetric load configuration enables to have nodes with different hardware architecture.

In the simplest load balancer topology with only two nodes in the cluster, the number of concurrent connections on a web server side can be as twice as high then on a particular node. But ...

    1 + 1 != 2

The upper statement means that the sum of allowed connections on a particular nodes does not give the total number of connections allowed. This means that each node has to allow a slightly higher number of connections than the desired total sum. This number is usually a 20% higher and it means that

    1 * 1.2 + 1 * 1.2 == 2

So if you wish to have a 100 concurrent connections with two nodes, each of the node will have to handle the maximum of 60 connections. The 20% margin factor is experimental, and depends on the Apache server used. For prefork MPMs it can rise up to 50%, while for the NT or Netware its value is 0%. The reason for that is that each particular child process menages its own balance statistics thus giving this 20% error for multiple child process web servers.

    worker.node1.type=ajp13

worker.node1.host=10.0.0.10

worker.node1.lbfactor=1



worker.node2.type=ajp13

worker.node2.host=10.0.0.11

worker.node2.lbfactor=2



worker.node3.type=ajp13

worker.node3.host=10.0.0.12

worker.node3.lbfactor=1



worker.list=lbworker

worker.lbworker.type=lb

worker.lbworker.balance_workers=node1,node2,node3    

The minimum configuration for a three node cluster shown in the upper example will give the 25%-50%-25% distribution of the load, meaning that the node2 will get as much load as the rest of the two members. It will also impose the following number of maxProcessors for each particular node in case of the MaxClients=200.

    node1 :

<Connector ... maxProcessors="60" ... />

node2 :

<Connector ... maxProcessors="120" ... />

node3 :

<Connector ... maxProcessors="60" ... />

Using simple math the load should be 50-100-50 but we needed to add the 20% load distribution error. In case this 20% additional load is not sufficient, you will need to set the higher value up to the 50%. Of course the average number of connections for each particular node will still follow the load balancer distribution quota.

Sticky sessions and failower

One of the major problems with having multiple backend application servers is determining the client-server relationship. Once the client makes a request to a server application that needs to track user actions over a designated time period, some sort of state has to be enforced inside a stateless http protocol. Tomcat issues a session identifier that uniquely distinguishes each user. The problem with that session identifier is that he does not carry any information about the particular Tomcat instance that issued that identifier.

Tomcat in that case adds an extra jvmRoute configurable mark to that session. The jvmRoute can be any name that will uniquely identify the particular Tomcat instance in the cluster. On the other side of the wire the mod_jk will use that jvmRoute as the name of the worker in it's load balancer list. This means that the name of the worker and the jvmRoute must be equal.

jvmRoute is appended to the session identifier :

http://host/app;jsessionid=0123456789ABCDEF0123456789ABCDEF.jvmRouteName

When having multiple nodes in a cluster you can improve your application availability by implementing failover. The failover means that if the particular elected node can not fulfill the request the another node will be selected automatically. In case of three nodes you are actually doubling your application availability. The application response time will be slower during failover, but none of your users will be rejected. Inside the mod_jk configuration there is a special configuration parameter called worker.retries that has default value of 3, but that needs to be adjusted to the actual number of nodes in the cluster.

    ...

worker.list=lbworker

worker.lbworker.type=lb

# Adjust to the number of workers

worker.retries=4

worker.lbworker.balance_workers=node1,node2,node3,node4    

If you add more then three workers to the load balancer adjust the retries parameter to reflect that number. It will ensure that even in the worse case scenario the request gets served if there is a single operable node. Of course, the request will be rejected if there are no free connections available on the Tomcat side , so you should increase the allowed number of connections on each Tomcat instance. In the three node scenario (1-2-1) if one of the nodes goes down, the other two will have to take its load. So if the load is divided equally you will need to set the following Tomcat configuration:

    node1 :

<Connector ... maxProcessors="120" ... />

node2 :

<Connector ... maxProcessors="160" ... />

node3 :

<Connector ... maxProcessors="120" ... />

This configuration will ensure that 200 concurrent connections will always be allowable no matter which of the nodes goes down. The reason for doubling the number of processors on node1 and node3 is because they need to handle the additional load in case node2 goes down (load 1-1). Node2 also needs the adjustment because if one of the other two nodes goes down, the load will be 1-2. As you can see the 20% load error is always calculated in.

Figure 4. Three node example load balancer

Figure 5. Failover for node2

As shown in the two figures above setting maxProcessors depends both on 20% load balancer error and expected single node failure. The calculation must include the node with the highest lbfactor as the worst case scenario.

Domain Clustering model

Since JK version 1.2.8 there is a new domain clustering model and it offers horizontal scalability and performance of tomcat cluster.

Tomcat cluster does only allow session replication to all nodes in the cluster. Once you work with more than 3-4 nodes there is too much overhead and risk in replicating sessions to all nodes. We split all nodes into clustered groups. The newly introduced worker attribute domain let mod_jk know, to which other nodes a session gets replicated (all workers with the same value in the domain attribute). So a load balancing worker knows, on which nodes the session is alive. If a node fails or is being taken down administratively, mod_jk chooses another node that has a replica of the session.

For example if you have a cluster with four nodes you can make two virtual domains and replicate the sessions only inside the domains. This will lower the replication network traffic by half

Figure 6. Domain model clustering

For the above example the configuration would look like:

    worker.node1.type=ajp13

worker.node1.host=10.0.0.10

worker.node1.lbfactor=1

worker.node1.domain=A



worker.node2.type=ajp13

worker.node2.host=10.0.0.11

worker.node2.lbfactor=1

worker.node2.domain=A



worker.node3.type=ajp13

worker.node3.host=10.0.0.12

worker.node3.lbfactor=1

worker.node3.domain=B



worker.node4.type=ajp13

worker.node4.host=10.0.0.13

worker.node4.lbfactor=1

worker.node4.domain=B



worker.list=lbworker

worker.lbworker.type=lb

worker.lbworker.balance_workers=node1,node2,node3,node4

Now assume you have multiple Apaches and Tomcats. The Tomcats are clustered and mod_jk uses sticky sessions. Now you are going to shut down (maintenance) one tomcat. All Apache will start connections to all tomcats. You end up with all tomcats getting connections from all apache processes, so the number of threads needed inside the tomcats will explode. If you group the tomcats to domain as explained above, the connections normally will stay inside the domain and you will need much less threads.

Fronting Tomcat with IIS

Just like Apache Web server for Windows, Microsoft IIS maintains a separate child process and thread pool for serving concurrent client connections. For non server products like Windows 2000 Professional or Windows XP the number of concurrent connections is limited to 10. This mean that you can not use workstation products for production servers unless the 10 connections limit will fulfil your needs. The server range of products does not impose that 10 connection limit, but just like Apache, the 2000 connections is a limit when the thread context switching will take its share and slow down the effective number of concurrent connections. If you need higher load you will need to deploy additional web servers and use Windows Network Load Balancer (WNLB) in front of Tomcat servers.

Figure 7. WNLB High load configuration

For topologies using Windows Network Load Balancer the same rules are in place as for the Apache with worker MPM. This means that each Tomcat instance will have to handle 20% higher connection load per node than its real lbfactor. The workers.properties configuration must be identical on each node that constitutes WNLB, meaning that you will have to configure all four Tomcat nodes.

Apache 2.2 and new mod_proxy

For the new Apache 2.1/2.2 mod_proxy has been rewriten and has a new AJP capable protocol module (mod_proxy_ajp) and integrated software load balancer (mod_proxy_balancer).

Because it can maintain a constant connection pool to backed servers it can replace the mod_jk functionality.

    LoadModule proxy_module modules/mod_proxy.so

LoadModule proxy_ajp_module modules/mod_proxy_ajp.so

LoadModule proxy_balancer_module modules/mod_proxy_balancer.so

...

<Proxy balancer://mycluster>

BalancerMember ajp://10.0.0.10:8009 min=10 max=100 route=node1 loadfactor=1

BalancerMember ajp://10.0.0.11:8009 min=20 max=200 route=node2 loadfactor=2    

</Proxy>

ProxyPass /servlets-examples balancer://mycluster/servlets-examples

The above example shows how easy is to configure a Tomcat cluster with proxy loadbalancer. One of the major advantages of using proxy is the integrated caching, and no need to compile external module.

Mod_proxy_balancer has integrated manager for dynamic parameter changes. It offers changing session routes or disabling a node for maintenance.

    <Location /balancer-manager>

SetHandler balancer-manager

Order deny,allow

Allow from localhost

</Location>

Figure 8. Changing BalancerMember parameters

The future development of mod_proxy will include the option to dynamically discover the particular node topology. It will also allow to dynamically update loadfactors and session routes.

About the Author

Mladen Turk is a Developer and Consultant for JBoss Inc in Europe, where he is responsible for native integration. He is a long time commiter for Jakarta Tomcat Connectors, Apache Httpd and Apache Portable Runtime projects.

A wide variety of topologies are appropriate for a DMZ environment, the basic locations of elements in a simple DMZ topology follow.

The main purpose of a DMZ configuration is to protect the business logic and data in the environment from unauthorized access. A typical DMZ configuration includes:

• An outer firewall between the public Internet and the Web server or servers processing the requests originating on the company Web site.
• An inner firewall between the Web server and the Application Servers to which it is forwarding requests. Company data also resides behind the inner firewall.

The area between the two firewalls gives the DMZ configuration its name. Additional firewalls can further safeguard access to databases holding administrative and application data.

• Avoids critical business data in the DMZ. A DMZ configuration protects application logic and data, by creating a buffer between the public Internet Web site and the internal intranet, where Application Servers and the data tier reside. Desirable DMZ topologies do not have databases or application servers with critical business data in the DMZ.

• Supports Network Address Translation (NAT). A firewall product that runs NAT receives packets for one IP address, and translates the headers of the packet to send the packet to a second IP address. In environments with firewalls employing NAT, avoid configurations involving complex protocols in which IP addresses are embedded in the body of the IP packet, such as Java Remote Method Invocation (RMI) or Internet Inter-Orb Protocol (IIOP). These IP addresses are not translated, making the packet useless.

• Avoids the DMZ protocol switch. The Web server sends HTTP requests to Application Servers behind firewalls. It is simplest to open an HTTP port in the firewall to let the requests through. Configurations that require switching to another protocol, such as IIOP, and opening firewall ports corresponding to the protocol, are less desirable. They are often more complex to set up, and the protocol switching overhead can impact performance.

• Allows an encrypted link between Web server and Application Server. Configurations that support encryption of communication between the Web server and application server reduce the risk that attackers are able to obtain secure information by sniffing packets sent between the Web server and Application Server. A performance penalty usually accompanies such encryption.

• Avoids a single point of failure. A point of failure exists when one process or machine depends on another process or machine. A single point of failure is especially undesirable because if the point fails, the whole system becomes unavailable. When comparing DMZ solutions, a single point of failure refers to a single point of failure between the Web server and Application Server. Various failover configurations can minimize downtime and possibly even prevent a failure. However, these configurations usually require additional hardware and administrative resources.

• Minimizes the number of firewall holes. Configurations that minimize the number of firewall ports are desirable because each additional firewall port leaves the firewall more vulnerable to attackers.

http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/ctop_firewall.html

Reverse proxy (IP forwarding)

Reverse proxy, or IP-forwarding topologies use a reverse proxy server to receive incoming HTTP requests and forward them to a Web server. The Web server forwards the requests to the Application Servers for actual processing. The reverse proxy returns completed requests to the client, hiding the originating Web server.

The following figure shows a simple reverse proxy topology.

In this example, a reverse proxy resides in a demilitarized zone (DMZ) between the outer and inner firewalls. It listens on an HTTP port, typically port 80, for HTTP requests. The reverse proxy then forwards such requests to an HTTP server that resides on the same machine as WebSphere Application Server. After the requests are fulfilled, they are returned through the reverse proxy to the client, hiding the originating Web server.

Typical use

Reverse proxy servers are typically used in DMZ configurations to provide additional security between the public Internet and the Web servers (and application servers) servicing requests.

Reverse proxy configurations support high performance DMZ solutions that require as few open ports in the firewall as possible. The reverse proxy capabilities of the Web server inside the DMZ require as few as one open port in the second firewall, potentially two if using Secure Sockets Layer (SSL) – port 443.

Advantages of using a reverse proxy server in a DMZ configuration include:

• The reverse proxy server does not need database access through the firewall.
• The reverse proxy configuration supports WebSphere Application Server security and NAT firewalls.
• The basic reverse proxy configuration is well known and tested in the industry, resulting in less customer confusion than other DMZ configurations.
• The reverse proxy configuration is reliable and its performance is relatively fast.
• The reverse proxy configuration eliminates protocol switching, by using the HTTP protocol for all forwarded requests.
• The reverse proxy server uses only one HTTP firewall port for requests and responses.

The reverse proxy configuration is also a disadvantage in some environments where security policies prohibit using the same port or protocol for inbound and outbound traffic across a firewall.

Disadvantages of using a reverse proxy server in a DMZ configuration include the following:

• The presence of a reverse proxy server in a DMZ is not suitable for some environments.
• The reverse proxy configuration requires more hardware and software than similar topologies that do not include a reverse proxy server, which makes it more complicated to configure and maintain.

http://publib.boulder.ibm.com/infocenter/wasinfo/v5r1//index.jsp?topic=/com.ibm.websphere.nd.doc/info/ae/ae/ctop_firewall.html

一、安装Tomcat和JDK

1、上传apache-tomcat-6.0.18.tar.gz和jdk-6u12-linux-i586.bin至/usr/local
2、执行如下命令安装tomcat：

解压完成后将apache-tomcat-6.0.18重命名为tomcat
3、执行如下命令安装JDK:

4、配置环境变量：
编辑/etc下的profile文件，加上如下内容：  

5、启动tomcat并输入http://localhost:8080，如果看到猫的页面即tomcat和jdk安装成功
6、新建文件目录/home/www为网站存放目录，设置server.xml文件，在Host name=”localhost”处将appBase=的指向路径改为/home/www/web
7、创建index.jsp至/home/www/web/ROOT，内容为：“My web!”  

二、安装Nginx
1、上传nginx-0.7.63.tar.gz至/usr/local

2、执行如下命令解压nginx：

3、编译安装nginx

执行完后会提示一个错误，说缺少PCRE library 这个是HTTP Rewrite 模块，也即是url静态化的包
可上传pcre-7.9.tar.gz，输入如下命令安装：

安装pcre成功后，继续安装nginx

4、nginx安装成功后的安装目录为/usr/local/nginx
在conf文件夹中新建proxy.conf，用于配置一些代理参数，内容如下：

编辑安装目录下conf文件夹中的nginx.conf，输入如下内容  

5、修改/usr/local/nginx/conf/nginx.conf配置文件后，请执行以下命令检查配置文件是否正确：

如果屏幕显示以下两行信息，说明配置文件正确：  

如果提示unknown host，则可在服务器上执行：ping www.baidu.com如果也是同样提示unknown host则有两种可能：
    a、服务器没有设置DNS服务器地址，查看/etc/resolv.conf下是否设置，若无则加上
    b、防火墙拦截

 6、启动nginx的命令

这时，输入以下命令查看Nginx主进程号：

7、停止nginx的命令

8、在不停止Nginx服务的情况下平滑变更Nginx配置
a、修改/usr/local/nginx/conf/nginx.conf配置文件后，请执行以下命令检查配置文件是否正确：

　　如果屏幕显示以下两行信息，说明配置文件正确：

b、这时，输入以下命令查看Nginx主进程号：

屏幕显示的即为Nginx主进程号，例如：
6302
这时，执行以下命令即可使修改过的Nginx配置文件生效：

　　
或者无需这么麻烦，找到Nginx的Pid文件：

9、nginx启动好后启动tomcat，此时输入http://主机ip地址即可看到“My web!” 

 
三、其他
stub_status
语法: stub_status on

默认值: None

作用域: location

创建一个 location 区域启用 stub_status

“stub status” 模块返回的状态信息跟 mathopd’s 的状态信息很相似. 返回的状态信息如下：

active connections — 对后端发起的活动连接数

server accepts handled requests — nginx 总共处理了 16630948 个连接, 成功创建 16630948 次握手 (证明中间没有失败的), 总共处理了 31070465 个请求 (平均每次握手处理了 1.8个数据请求)

reading — nginx 读取到客户端的Header信息数

writing — nginx 返回给客户端的Header信息数

waiting — 开启 keep-alive 的情况下，这个值等于 active – (reading + writing)，意思就是Nginx说已经处理完正在等候下一次请求指令的驻留连接

针对不同资源提供不同安全级别的保 护，可以考虑构建一个叫做“demilitarized zone”（dmz）的区域。dmz可以理解为一个不同于外网或内网的特殊网络区域。dmz内通常放置一些不含机密信息的公用服务器，比如web、 mail、ftp等。这样来自外网的访问者可以访问dmz中的服务，但不可能接触到存放在内网中的公司机密或私人信息等。即使dmz中服务器受到破坏，也 不会对内网中的机密信息造成影响。

许多防火墙产品都提供了dmz的接口。硬件防火墙由于 使用专门的硬件芯片，所以在性能和流量上有绝对的优势。软件防火墙的性价比非常好，一般企业使用起来效果不错。如果使用linux防火墙，其成本将更低。 因此这里将要介绍的是在linux防火墙上划分dmz区域的方法。

构建 dmz的策略

linux从2.4内核开始,正式使用iptables 来代替以前的ipfwadm和ipchains，实现管理linux的包过滤功能。linux的包过滤通过一个叫netfilter的内核部件来实现。 netfilter内建了三个表，其中默认表filter中又包括3个规则链，分别是负责外界流入网络接口的数据过滤的input链、负责对网络接口输出 的数据进行过滤的output链，以及负责在网络接口之间转发数据过滤的 forward链。要构建一个带dmz的防火墙，需要利用对这些链的设定完成。首先要对从连接外部网络的网卡(eth0)上流入的数据进行判断，这是在 input链上完成。如果数据的目标地址属于dmz网段，就要将数据转发到连接dmz网络的网卡（eth1）上；如果是内部网络的地址，就要将数据转发到 连接内部网络的网卡（eth2）上。表1显示了各个网络之间的访问关系。

表1 网络间访问关系表

内网 外网 dmz

内网 / y y

外 网 n / y

dmz n n /

根据表1，可以明 确以下六条访问控制策略。

1.内网可以访问外网

内网的用户显然需要自由 地访问外网。在这一策略中，防火墙需要进行源地址转换。

2.内网可以访问dmz

此 策略是为了方便内网用户使用和管理dmz中的服务器。

3.外网不能访问内网

很 显然，内网中存放的是公司内部数据，这些数据不允许外网的用户进行访问。

4.外网可以访 问dmz

dmz中的服务器本身就是要给外界提供服务的，所以外网必须可以访问dmz。同时，外网访问dmz需要由防火墙完成对外地址到服 务器实际地址的转换。

5.dmz不能访问内网

很明显，如果违背此策略， 则当入侵者攻陷dmz时，就可以进一步进攻到内网的重要数据。

6.dmz不能访问外网

此 条策略也有例外，比如dmz中放置邮件服务器时，就需要访问外网，否则将不能正常工作。

dmz 的实现

根据以上访问控制策略可以设定linux防火墙的过滤规则。下 面将在一个虚构的网络环境中，探讨如何根据以上六条访问控制策略建立相应的防火墙过滤规则。这里的讨论和具体应用会有所区别，不过这种讨论将有助于实际应 用。用户在实际应用时可根据具体的情况进行设置。该虚拟环境的网络拓扑如图1。

图1 dmz网络拓扑图

如图1所示，路由器连接internet和防火墙。作为防火墙的linux服 务器使用三块网卡：网卡eth0与路由器相连，网卡 eth1与dmz区的hub相连，网卡eth2与内网hub相连。作为一个抽象的例子，我们用“[内网地址]”来代表“192.168.1.0/24”之 类的具体数值。同理还有“[外网地址]”和“[dmz地址]”。

对于防火墙，原则之一就 是默认禁止所有数据通信，然后再打开必要的通信。所以在防火墙脚本的最初，需要清空系统原有的规则，然后将input、output、forward的默 认规则设置为丢弃所有数据包。

对应的防火墙脚本片段如下： # flush out the tables and delete all user-defined chains

/sbin/iptables -f

/sbin/iptables -x

/sbin/iptables -t nat -f

/sbin/iptables -t nat -x

六种策略的实现。

1.内网可以访问外网

对应的防火墙脚本片段如下：

/sbin/iptables -t nat -a postrouting -s [内网地址] -d [外网地址] -o eth0 -j snat --to [nat的真实ip]

当数据从连接外网的eth0流出时，要将来自内网的数据包的源地址改成internet上的真实ip，这样才能和外网的主机进行通 信。“[nat的真实ip]”表示分配给nat用户的真实ip，有几个就写几个，以空格分开，但至少要写一个。

2.内网可以访问dmz

对应的防火墙脚本片段如下：

/sbin/iptables -a forward -s [内网地址] -d [dmz地址] -i eth2 -j accept

以上命令允许所有来自内网、目的地为 dmz的数据包通过。

3.外网不能访问内网

对应的防火墙脚本片段如下：

/sbin/iptables -t nat -a prerouting -s [外网地址] -d [内网地址] -i eth0 -j drop

以上命令将来自 外网、去往内网的数据包全部丢弃。

4.外网可以访问dmz

为了保护 dmz中的服务器，外网对dmz的访问也要加以限制。通常的思路是，只允许外网访问dmz中服务器所提供的特定服务，比如http。

对应 的防火墙脚本片段如下：

/sbin/iptables -t nat -a prerouting -p tcp --dport 80 -d [分配给http服务器的internet上的真实ip] -s [外网地址] -i eth0 -j dnat --to [http服务器的实际ip]

/sbin/iptables -a forward -p tcp -s [外网地址] -d [http服务器的实际ip] -i eth0 --dport 80 -j accept

/sbin/iptables -a forward -p tcp -d [外网地址] -s [http服务器的实际ip] -i eth1 --sport 80 ! --syn -j accept

/sbin/iptables -t nat -a prerouting -s [外网地址] -d [dmz地址] -i eth0 -j drop

该防火墙脚本片段将开放http服务，使得只有访问 dmz中http服务的数据包才能通过防火墙。

5.dmz不能访问内网

对 应的防火墙脚本片段如下：

/sbin/iptables -a forward -s [dmz地址] -d [内网地址] -i eth1 -j drop

以上命令将丢弃所有从dmz到内网的数据包。

6.dmz 不能访问外网

对应的防火墙脚本片段如下：

/sbin/iptables -t nat -a postrouting -p tcp --dport 25 -d [外网地址] -s [邮件服务器的ip] -o eth0 -j snat --to [分配给smtp服务器的internet上的真实ip]

/sbin/iptables -a forward -p tcp -s [邮件服务器的ip] -d [外网地址] -i eth1 --dport 25 -j accept

/sbin/iptables -a forward -p tcp -d [邮件服务器的ip] -s [外网地址] -i eth0--sport 25 ! --syn -j accept

以上命令先允许dmz中邮件服务器连接外网的smtp服务端口(25)，然 后禁止其它从dmz发往外网的数据包。

针对以上基本策略例举了实现它们的基本规则。在实 际应用中，需要根据具体情况进行设置。只要设置得当，linux也能成为很好的防火墙。需要补充的是，无论何种防火墙都只能提供有限的保护。设置好防火墙 不等于网络就是安全的，关键在于综合运用各种安全手段。

SEP11客户端病毒定义更新失败问题的解决办法
在最新的SEP11版本上目前仍然保留了SAV时代产品的Liveupdate模块的功能，并进一步完善了internal liveupdate server 的使用功能，使得内容及产品的更新更易于管理。
很多用户会经常碰到SEP客户端，下载病毒定义失败的问题，本文将详解，SEP产品在通过Liveupdate模块来更新病毒定义及威胁检测特征库中所碰到的一些失败情况的分析及解决办法。
SEP客户端病毒定义通过LIVEUPDATE进行更新碰到一些失败经常是由于本地病毒定义文件损坏造成的，要重新PUSH进新的病毒定义就需要删除掉一些旧的损坏的病毒定义内容，这就必须知道病毒定义是如何从外界导入本地环境的具体路径。
病毒定义损坏界面：
对于客户端从INTERNET获取病毒定义，经过两步过程
1 liveupdate 模块下载病毒定义到本地的C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads路径下。下载的初始过程都是由一些零散的小的TMP块文件组成，然后会有自动的机制将这些文件重新整合成一些压缩文件，然后这些临时文件会在LIVEUPDATE过程结束后，全部消失，如图中所示下载过程及文件消失过程：
下载完成临时文件消失：
2 当Download文件夹下所有的TMP块文件消失后，这些文件将在另外一个目录下C:\Program Files\Common Files\Symantec Shared\VirusDefs。进行解压以供客户端来使用。解压的过程中也会伴随产生一些TMP文件夹和LOCK文件，但这些文件将在顺利解压完成后会马上消失。
临时文件消失：
明白了这个路径，下面就需要确定如何删除哪些损坏的定义文件了，其具体步骤为：
1 在服务管理器中停止当前所有的SEP的服务进程
2 删除C:\Documents and Settings\All Users\Application Data\Symantec\LiveUpdate\Downloads
目录下的所有内容。
3 删除C:\Program Files\Common Files\Symantec Shared\VirusDefs目录下的如下文件
usage.dat/definfo.dat    /    及texthub,binhub,incoming 子文件夹下的所有内容（注意这里不是删除
文件夹而是删除文件夹下的内容，最后要保留个空文件夹）
其中definfo.dat中有病毒定义更新的日期记录，binhub中包含当前病毒定义文件副本，用来做恢复当前病
毒定义的作用，所以这些文件一定都要删除干净。另外在Virusdefs目录下可能还会存有一些带有日期的文
件夹这些就是每个历史时期保留下来的病毒定义文件，建议不要删除所有的带有日期的文件夹，保留一个
definfo.dat文件中 "lastdefs=日期A" 日期A对应的文件夹，其余的日期文件夹都删除掉。
definfo.dat 文件样本如下，删除20080203.006，保留20080202.003 文件夹
[DefDates]
CurDefs=20080203.006
LastDefs=20080202.003
剩下的工作就是重新启动SEP的各项服务，并点击LIVEUPDATE进行升级，就OK 了 

在QQ2009 Beta版的时候，可以通过删除一些文件让非会员也能实现去广告的目的，可惜QQ2009正式版起增加了文件完整性检查，删除文件会导致QQ无法启动，并要求重新安装，那么对于非会员来说，QQ2009正式版（包括之后的SP1、SP2等）就不能手动去广告了吗？

其实还是有办法的，而且做起来也不难，你说是用第三方工具？不需要，只要你对操作系统稍有了解就可以轻松搞定。下面就把小编找到的方法共享给大家。

　　1、去除腾讯迷你首页：

　　对于每次启动QQ后，都弹出的“腾讯迷你首页”，很多人一定感到不爽，就让我们先拿它开刀吧。

　　首先进入QQ的安装文件夹，接着进入 Plugin＼Com.Tencent.Advertisement＼bin 文件夹，这里你会看到一个Advertisement.dll文件，它就是迷你首页的关键所在，只需将这个文件改成只读属性，以后启动QQ就不会再看到迷你首页了。

　　2、去除聊天窗口右上角广告：

　　这个操作针对XP和Vista/Win7略有不同，主要是文件夹路径上的。

　　XP：

　　进入 X（系统所在盘）:＼Documents and Settings＼用户名＼Application Data＼Tencent＼QQ＼Misc＼com.tencent.advertisement，首先删除这个文件夹里面的所有文件，注意文件夹本身不能删除，然后把当前用户的写入权限给拒绝掉（需要当前分区为NTFS格式）。方法：文件夹上右键，属性 - 安全标签，选中当前登录用户，接着在下方“写入”权限里，拒绝上打勾。

　　Vista/Windows 7

　　进入X:＼users＼用户名＼appdata＼Roaming＼Tencent＼QQ＼Misc＼com.tencent.advertisement，之后操作同XP。

　　3、去除聊天窗口左下角广告

　　如今的聊天窗口，除了右上角的图片广告外，左下角还多了一条文字广告，既然要去广告，那么这块自然也不能遗忘。同样操作针对XP和Vista有所不同。

　　XP：

　　首先要关闭QQ，然后进入X:＼Documents and Settings＼用户名＼Application Data＼Tencent＼Users＼你的QQ号＼QQ＼，删除其中的Misc.db，接着新建一个文件夹并命名为Misc.db。（是不是和防止U盘自动运行病毒的方法很像）

　　Vista/Windows 7

　　关闭QQ后，进入X:＼users＼用户名＼appdata＼Roaming＼Tencent＼Users＼你的QQ号码＼QQ＼，然后操作同上。

　　怎么样，这样一处理以后，3个地方的广告是不是消失了？另外，你有没有觉得登录速度似乎也有所加快？

http://groups.google.com/groups?selm=O4yhAYjdEHA.996%40TK2MSFTNGP12.p...

(the "sc sdset bits ..." part in the link above)

Then, after the above, do the following:

Click Start >> Run >>
Type the follow command in the Open box.
"regsvr32.exe qmgr.dll"     (w/o quotes)
Press Ok

Repeat the same for the following command:

regsvr32.exe qmgrprxy.dll

If that didn't help, try this:

Run this command line (from a command prompt of from Start/Run, it
reinstalls the BITS service (line will wrap in the newsreader!):

%SystemRoot%\System32\rundll32.exe setupapi,InstallHinfSection DefaultInstall
  132 %SystemRoot%\inf\qmgr.inf

(it must be a space between DefaultInstall and 132)

When it asks for your OS CD-ROM to get some files, just point it to the
folder %windir%\System32 (%windir% is typically C:\Windows).

Then run the following commands:

regsvr32.exe qmgr.dll
regsvr32.exe qmgrprxy.dll

Do a reboot after this.

      （1）SQL语句硬分析(Hard Parse)太多，严重消耗CPU资源，延长了SQL语句总的执行时间

        SQL语句的执行过程分几个步骤：语法检查、分析、执行、返回结果。其中分析分为硬分析(Hard Parse)和软分析(Soft Parse)。一条SQL语句通过语法检查后，Oracle 会先去shared pool 中找是否有相同的sql，如果找着了，就叫软分析，然后执行SQL语句。硬分析主要是检查该sql所涉及到的所有对象是否有效以及权限等关系，然后根据RBO或CBO模式生成执行计划，然后才执行SQL语句。

   可以看出，硬分析比软分析多了很多动作，而这里面的关键是“在shared pool 中是否有相同的sql”，而这就取决于是否使用绑定变量。

      另：oracle9i引入了soft soft parse，先到pga中的session cursor cache list列表中去查找（session cursor cache list的长度是由session_cache_cursor参数决定的），如果没有找到这条sql，这时候才去检查shard_pool.   对于Oltp系统，很多时候硬分析的代价比执行还要高，这个我们可以通过10046事件跟踪得知。

    （2）共享池中SQL语句数量太多，重用性极低，加速了SQL语句的老化，导致共享池碎片过多。

      共享池中不同的SQL语句数量巨大，根据LRU原则，一些语句逐渐老化，最终被清理出共享池；这样就导致shared_pool_size 里面命中率下降，共享池碎片增多，可用内存空间不足。而为了维护共享池内部结构，需要使用latch，一种内部生命周期很短的lock，这将使用大量的cpu 资源，使得性能急剧下降。

      不使用绑定变量违背了oracle 的shared pool 的设计的原则，违背了这个设计用来共享的思想。

2、怎么查看没有使用绑定变量

select * from v$sql or v$sqlarea 查看是否有很多类似的语句，除了变量不一样，其他的都一样

3、如何使用绑定变量？

编写java 程序时，我们习惯都是定义JAVA 的程序变量，放入SQL 语句中，如

String v_id = 'xxxxx';

String v_sql = 'select name from table_a where id = ' + v_id ;

以上代码，看起来是使用了变量v_id ，但这却是java 的程序变量，而不是oracle 的绑定变量，语句传递到数据库后，此java 的程序变量

已经被替换成具体的常量值，变成：

select * from table_a where name = 'xxxxx' ;

假定这个语句第一次执行，会进行硬分析。后来，同一段java 代码中v_id 值发现变化（v_id = 'yyyyyy'），数据库又接收到这样的语句：

select * from table_a where name = 'yyyyyy' ;

ORACLE 并不认为以上两条语句是相同的语句，因此对第二条语句会又做一次硬分析。这两条语句的执行计划可是一样的！

其实，只需将以上java 代码改成以下这样，就使用了oracle 的绑定变量：

String v_id = 'xxxxx';

String v_sql = 'select name from table_a where id = ? '; //嵌入绑定变量

stmt = con.prepareStatement( v_sql );

stmt.setString(1, v_id ); //为绑定变量赋值

stmt.executeQuery();

在Java中，结合使用setXXX 系列方法，可以为不同数据类型的绑定变量进行赋值，从而大大优化了SQL 语句的性能。

4、java中应用绑定变量的例子

PreparedStatement stmt = conn.prepareStatement('select a from b where c = ? ');

stmt.setLong(1,123);

stmt.executeQuery()

……

结论：

    绑定变量主要适用在Oltp，运行时间很短的系统。如客服系统，时时地进行insert方面的系统。 数据仓库系统不适用，和数据库仓库系统的一条sql运行时间相比，硬分析的代价显然是微不足道的，通过硬分析去选择正确的执行计划才是关键。

  简单一句话，在Oltp系统中应用绑定变量，性能会有质的提高。

                                                                                                                ---引（http://www.apub.org/doc/2006/03/11/10/52/26/21883.html）

       Strategy 策略模式是一种对象行为模式。主要是应对：在软件构建过程中，某些对象使用的算法可能多种多样，经常发生变化。如果在对象内部实现这些算法，将会使对象变得异常复杂，甚至会造成性能上的负担。

       GoF 《设计模式》中说道：定义一系列算法，把它们一个个封装起来，并且使它们可以相互替换。该模式使得算法可独立于它们的客户变化。

       Strategy 模式的结构图如下：

       从图中我们不难看出： Strategy 模式实际上就是将算法一一封装起来，如图上的 ConcreteStrategyA 、 ConcreteStrategyB 、 ConcreteStrategyC ，但是它们都继承于一个接口，这样在 Context 调用时就可以以多态的方式来实现对于不用算法的调用。

       Strategy 模式的实现如下：

       我们现在来看一个场景：我在下班在回家的路上，可以有这几种选择，走路、骑车、坐车。首先，我们需要把算法抽象出来：

       public interface IStrategy

    {

        void OnTheWay();

}

接下来，我们需要实现走路、骑车和坐车几种方式。

public class WalkStrategy : IStrategy

    {

        public void OnTheWay()

        {

            Console.WriteLine("Walk on the road");

        }

    }

    public class RideBickStragtegy : IStrategy

    {

        public void OnTheWay()

        {

            Console.WriteLine("Ride the bicycle on the road");

        }

    }

    public class CarStragtegy : IStrategy

    {

        public void OnTheWay()

        {

            Console.WriteLine("Drive the car on the road");

        }

}

最后再用客户端代码调用封装的算法接口，实现一个走路回家的场景：

class Program

    {

        static void Main(string[] args)

        {

            Console.WriteLine("Arrive to home");

            IStrategy strategy = newWalkStrategy();

            strategy.OnTheWay();

            Console.Read();

        }

}

运行结果如下；

Arrive to home

Walk on the road

如果我们需要实现其他的方法，只需要在 Context 改变一下 IStrategy 所示例化的对象就可以。

       Strategy 模式的要点：

1 、 Strategy 及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便地根据需要在各个算法之间进行切换。所谓封装算法，支持算法的变化。

2 、 Strategy 模式提供了用条件判断语句以外的另一中选择，消除条件判断语句，就是在解耦合。含有许多条件判断语句的代码通常都需要 Strategy 模式。

3 、 Strategy 模式已算法为中心，可以和 Factory Method 联合使用，在工厂中使用配制文件对变化的点进行动态的配置。这样就使变化放到了运行时。

4 、与 Template Method 相比， Strategy 模式的中心跟集中在方法的封装上

行为模式：

行为型模式涉及到算法和对象间职责的分配。将注意力从控制流转移到对象间的联系方式上来。

       行为模式分为：行为类模式和行为对象模式。行为类模式使用继承机制在类间分派行为；行为对象模式使用对象复合而不是继承。

Template Method 模板方法模式

       Template Method 模板方法模式介绍：

       Template Method 模板方法模式是一种行为型模式，具体点说是行为类型模式。主要解决在软件构建过程中，对于某一项任务，常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因而无法和任务的整体结构同时实现。

       GoF 《设计模式》中说道：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。 Template Method 使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤

       Template Method 模式的结构

       定义场景

       单看结构不好理解，我们来结合程序进行分析。现在定义一个场景：我想大家都玩过极品飞车（我相当喜欢）。游戏中有很多的汽车，但是从操作角度看大同小异。无非是起步（ StartUp ）、行驶（ Run ）、停车（ Stop ）等等行为。汽车行驶的动作之间可能存在着差异，例如：手动档和自动档，但是接口是一样的，换句话说，基本都是这几个动作。结合 Template Method 模式讲就是在这个程序中，结构（对汽车的操作）是稳定的，但是变化在于各个子步骤（操作行为的具体实现）。

       程序实现与结构分析

       首先我们需要一个汽车的抽象类（结构图中的 AbstractClass ）

       public abstract class AbstractCar

    {

        protected abstract string StartUp();

        protected abstract string Run();

        protected abstract string Stop();

        public void DriveOnTheRoad()

        {

            Console.WriteLine(StartUp());

            Console.WriteLine(Run());

            Console.WriteLine(Stop());

        }

}

在这段代码中，抽象方法StartUp、Run、Stop叫做primitive operation（原语操作），它们是在子类中的扩展点，例如我们要编写一辆BORA的实现，在他继承AbstractCar后，可以在这几个primitive operation上进行自己个步骤的实现。

AbstractCar 中的DriveOnTheRoad方法叫做template method（模板方法），template method用primitive operation定义一个算法，是相对稳定的部分。（子类中重新定义primitive operation）。

    然后我们要实现一辆BORA汽车（结构图中的ConcreteClass）

    public class BORA : AbstractCar

    {

        protected override string StartUp()

        {

            return "BORA is StartUp";

        }

        protected override string Run()

        {

            return "BORA is Running";

        }

        protected override string Stop()

        {

            return "BORA is Stoped";

        }

}

接下来我们进行客户程序的实现

class Program

    {

        static void Main(string[] args)

        {

            ClientApp.Drive(newBORA());

            Console.Read();

        }

}

public class ClientApp

    {

        public static void Drive(AbstractCar car)

        {

            car.DriveOnTheRoad();

        }

}

运行结果如下：

BORA is StartUp

BORA is Running

BORA is Stoped

Template Method 要点

1、  Template Method 模式是一种非常基础性的设计模式，在面向对象系统中有着大量的应用。它用最简洁的机制（虚函数的多态性）为了很多应用程序框架提供了灵活的扩展点，是代码复用方面的基本实现结构。

2、  除了可以灵活应对子步骤的变化外，“ Don't call me.Let me Call you ”的反向控制结构是 Template Method 的典型应用。“ Don’t call me.Let me Call you ”是指一个父类调用一个子类的操作，而不是相反。

3、  在具体实现方面，被 Template Method 调用的虚方法可以具有实现，也可以没有任何实现（抽象方法、纯虚方法），但一般推荐将它们设置为 protected 方法。可以没有具体实现的方法应该称为 hook operation （钩子操作），提供了缺省的行为，子类可以在必要时进行扩展。

4、  尽量减少 primitive operation ，因为需要重新定义的操作越多，客户程序就越长

   在学习的过程中感觉，从代码的角度看 Adapter 适配器模式和 Proxy 代理模式有些类似， Adapter 适配器模式是解决现有对象在新的环境中的不足，而 Proxy 代理模式是解决直接访问对象时出现的问题，这两种模式从使用角度看都是解决直接访问对象时出现的问题，只是含义不十分相同。

在学习的过程中，觉得从功能上看 Abstract Factory 模式和 Builder 模式容易混淆， Factory Method 模式和 Prototype 模式不好区分。 Singleton 模式没什么太大的困难。下面就来分析一下前四种模式。

一、 Abstract Factory 模式和 Builder 模式：

Abstract Factory 是应对一系列对象的创建的问题，正如前面文章中举的例子，对于创建一个汽车对象来说， Abstract Factory 模式更关注一系列的对象的创建，或者说是汽车类型中的各个部分，如： Wheel 、 Engine 、 Body 等等类型的创建。换句话说关注点在这一系列对象上。

Builder 是应对一个复杂对象创建的问题，或者说是针对这个复杂对象中的子对象的创建的问题。以汽车的例子来说，我觉得比起 Abstract Factory 模式， Builder 模式相对注重汽车类型（上面所说的“复杂对象”）本身以及其各个部分（ Wheel 、 Engine 、 Body 等等）类型的创建。 Builder 模式要求这个复杂的类型（汽车）中的各个子类型的结合部分相对稳定，用例子说明就是对于汽车来说，无论用什么配件组装，个个配件的组装方式都一样，有相对稳定的接口。对于这辆车你用什么牌子的 Wheel 、什么牌子的 Engine 可能变化会很大很频繁。

二、 Factory Method 模式和 Prototype 模式：

开始我觉得这两种模式从功能上讲是一样的（个人观点），都是封装了对对象的创建，只不过 Prototype 模式是用 原型克隆 进行拷贝来完成对象的创建，在这之中还应注意浅拷贝和深拷贝的区别。在向同事请教后有点明白。这两种模式在应用场景上还是一定的区别的。

Factory Method 模式是重新创建一个对象

Prototype 模式是利用现有的对象进行克隆，当两个对象或多个对象雷同的时候，可以考虑用一个已创建的对象去克隆出其余的对象。
   以上是对创建型模式的总结，如有不对的观点欢迎指正。

代 理模式是一种结构型设计模式，主要解决的问题是：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些 原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时 加上一个对此对象的访问层。如下图：
   

       比如说 C 和 A 不在一个服务器上， A 要频繁的调用 C ，我们可以在 A 上做一个代理类 Proxy ，把访问 C 的工作交给 Proxy ，这样对于 A 来说，就好像在直接访问 C 的对象。在对 A 的开发中我们可以把注意力完全放在业务的实现上。

       GoF 《设计模式》中说道：为其他对象提供一种代理以控制这个对象的访问。

       Proxy 模式的结构：
   

       下面通过一个场景来看看 Proxy 的实现，我们要使用代理类型 ProxyClass 的对象调用远程机器上的一个类型 LongDistanceClass 的对象。

    首先我们先模拟一个远程的类型：为了保持对被代理对象使用的透明性，我们使代理类型和被代理类型同时继承同一个接口IProxy

    接口实现：

    interface IProxy

    {

        string Function1();

        string Function2();

    }

    远程对象实现：

    /// <summary>

    /// 模拟的远程对象

    /// </summary>

    public class LongDistanceClass:IProxy

    {

        #region IProxy 成员

        public string Function1()

        {

            //do someting

            return "LongDistanceClass.Function1";

        }

        public string Function2()

        {

            //do someting

            return "LongDistanceClass.Function2";

        }

        #endregion

    }

    接下来就要实现代理类型，使用代理对象访问模拟的远程对象，代理类型实现如下：

    public class ProxyClass:IProxy

    {

        #region IProxy 成员

        public string Function1()

        {

            //to access LongDistanceClass.Function1

            LongDistanceClass obj = new LongDistanceClass();

            return obj.Function1();

        }

        public string Function2()

        {

            //to access LongDistanceClass.Function2

            LongDistanceClass obj = new LongDistanceClass();

            return obj.Function2();

        }

        #endregion

    }

    最后实现客户端代码：

    class Class1

    {

        [STAThread]

        static void Main(string[] args)

        {

            IProxy pro = new ProxyClass();

            Console.WriteLine(pro.Function1());

            Console.WriteLine(pro.Function2());

            Console.Read();

        }

    }

    运行结果如下：

    LongDistanceClass.Function1

LongDistanceClass.Function2

       Proxy 模式的要点：

       1 、“增加一层间接层”是软件系统中对许多负责问题的一种常见解决方法。在面向对象系统中，直接使用某些对象会带来很多问题，作为间接层的 proxy 对象便是解决这一问题的常用手段。

       在我们日常的工作中也常常用到代理模式，比如对于三层结构或者 N- tiers 结构中 DAL 数据访问层，它把对数据库的访问进行封装。 BLL 业务层的开发者只是调用 DAL 中的方法来获得数据。

       在比如前一段时间看了看 AOP 和 Remoting 方面的资料，对于跨越应用程序域的访问，要为客户应用程序提供一个 TransparentProxy （透明代理），客户程序实际上是通过访问这个代理来访问实际的类型对象。

2 、具体 proxy 设计模式的实现方法、实现粒度都相差很大，有些可能对单个对象作细粒度的控制，有些可能对组件模块提供抽象代理层，在架构层次对对象作 proxy 。

3 、 proxy 并不一定要求保持接口的一致性，只要能够实现间接控制，有时候损及一些透明性是可以接受的。例如上面的那个例子，代理类型 ProxyClass 和被代理类型 LongDistanceClass 可以不用继承自同一个接口，正像 GoF 《设计模式》中说的：为其他对象提供一种代理以控制这个对象的访问。代理类型从某种角度上讲也可以起到控制被代理类型的访问的作用。

GoF 《设计模式》中说道：为子系统中的一组接口提供一个一致的界面， Facade 模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

Façade 外观模式的结构大概是这样的：

       这个图是我对 Facade 模式的理解，如果大家觉得有什么不对的地方欢迎给我指出。

       我就上面说的那个情形写一下实现代码，首先我们要实现三个子系统（ Wheel 、 Engine 、 Body ）：

       internal class Engine

    {

        public string EngineWork()

        {

            return "BMW's Engine is Working";

        }

        public string EngineStop()

        {

            return "BMW's Engine is stoped";

        }

    }

    internal class Wheel

    {

        public string WheelCircumrotate()

        {

            return "BMW's Wheel is Circumrotating";

        }

        public string WheelStop()

        {

            return "BMW's Wheel is stoped";

        }

    }

    internal class Body

    {

        public Wheel[] wheels = newWheel[4];

        public Engine engine = newEngine();

        public Body()

        {

            for (int i = 0; i < wheels.Length; i++)

            {

                wheels[i] = newWheel();

            }

        }

}

然后，我们再来实现汽车的Facade

class CarFacade

    {

        Body body = newBody();

        public void Run()

        {

            Console.WriteLine(body.engine.EngineWork());

            for(int i = 0; i < body.wheels.Length; i++)

            {

                Console.WriteLine(body.wheels[i].WheelCircumrotate());

             }

        }

        public void Stop()

        {

            Console.WriteLine(body.engine.EngineStop());

            for (int i = 0; i < body.wheels.Length; i++)

            {

                Console.WriteLine(body.wheels[i].WheelStop());

            }

        }

}

现在我们来使用客户端程序验证一下，代码如下：

class Program

    {

        static void Main(string[] args)

        {

            CarFacade car = newCarFacade();

            car.Run();

            car.Stop();

            Console.Read();

        }

}

       执行结果如下；

       BMW's Engine is Working

BMW's Wheel is Circumrotating

BMW's Wheel is Circumrotating

BMW's Wheel is Circumrotating

BMW's Wheel is Circumrotating

BMW's Engine is stoped

BMW's Wheel is stoped

BMW's Wheel is stoped

BMW's Wheel is stoped

BMW's Wheel is stoped

正如上面所说：客户端代码（ Program ）不需要关心子系统，它只需要关心 CarFacade 所留下来的和外部交互的接口，而子系统是在 CarFacade 中聚合。

Façade 模式的几个要点：

       1 、从客户程序的角度看， Facade 模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到 Facade 接口的变化。

2 、 Facade 设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。 Facade 很多时候更是一种架构设计模式。

GoF 《设计模式》中说道：动态的给一个对象添加一些额外的职责。就增加功能而言， Decorator 模式比生成子类更为灵活。

下面来看看 Decorator 模式的结构：

看这个结构好像不是很明白，下面我根据代码讲解一下这个结构。我想了一个场景：我们现在用的手机功能很多，我就用 Decorator 模式实现一下对某个手机的 GSP 和蓝牙功能扩展。

首先，我们需要一个手机的接口或者是抽象类，我这里就用抽象类来实现，代码如下：

public abstract class AbstractCellPhone

    {

        public abstract string CallNumber();

        public abstract string SendMessage();

}

AbstractCellPhone 也就是结构图中的Component，然后，我再来实现Nokia和Moto的手机类，这类要继承AbstractCellPhone，也就是图中ConcreteComponent类要继承Component，实现代码如下：

public class NokiaPhone : AbstractCellPhone

    {

        public override string CallNumber()

        {

             return "NokiaPhone call sombody";

        }

        public override string SendMessage()

        {

            return "NokiaPhone send a message to somebody";

        }

    }

    public class MotoPhone : AbstractCellPhone

    {

        public override string CallNumber()

        {

            return "MotoPhone call sombody";

        }

        public override string SendMessage()

        {

            return "MotoPhone send a message to somebody";

        }

 }   

接下来我需要一个Decorator接口或者抽象类，实现代码如下：

public abstract class Decorator:AbstractCellPhone

    {

        AbstractCellPhone _phone;

        public Decorator(AbstractCellPhone phone)

        {

            _phone = phone;

        }

        public override string CallNumber()

        {

            return _phone.CallNumber();

        }

        public override string SendMessage()

        {

            return _phone.SendMessage();

        }

  }

正如结构图中，这个Decorator即继承了AbstractCellPhone，又包含了一个私有的AbstractCellPhone的对象。这样做的意义是： Decorator 类又使用了另外一个 Component 类。我们可以使用一个或多个 Decorator 对象来“装饰”一个 Component 对象，且装饰后的对象仍然是一个 Component 对象。 在下来，我要实现GSP和蓝牙的功能扩展，它们要继承自Decorator，代码如下：

public class DecoratorGPS : Decorator

    {

        public DecoratorGPS(AbstractCellPhone phone)

            : base(phone)

        { }

        public override string CallNumber()

        {

            return base.CallNumber() + " with GPS";

        }

        public override string SendMessage()

        {

            return base.SendMessage() + " with GPS";

        }

     }

    public class DecoratorBlueTooth : Decorator

    {

        public DecoratorBlueTooth(AbstractCellPhone phone)

            : base(phone)

        { }

        public override string CallNumber()

        {

            return base.CallNumber() + " with BlueTooth";

        }

        public override string SendMessage()

        {

            return base.SendMessage() + " with BlueTooth";

        }

 }

最后，用客户端程序验证一下：

static void Main(string[] args)

        {

             AbstractCellPhone phone = newNokiaPhone();

            Console.WriteLine(phone.CallNumber());

            Console.WriteLine(phone.SendMessage());

            DecoratorGPS gps = newDecoratorGPS(phone);     //add GSP

            Console.WriteLine(gps.CallNumber());

            Console.WriteLine(gps.SendMessage());

            DecoratorBlueTooth bluetooth = newDecoratorBlueTooth(gps); //add GSP and bluetooth

            Console.WriteLine(bluetooth.CallNumber());

            Console.WriteLine(bluetooth.SendMessage());

            Console.Read();

     }

执行结果：

NokiaPhone call sombody

NokiaPhone send a message to somebody

NokiaPhone call sombody with GPS

NokiaPhone send a message to somebody with GPS

NokiaPhone call sombody with GPS with BlueTooth

NokiaPhone send a message to somebody with GPS with BlueTooth

从执行的结果不难看出扩展功能已被添加。最后再说说 Decorator 装饰模式的几点要点：

1 、通过采用组合、而非继承的手法， Decorator 模式实现了在运行时动态的扩展对象功能的能力，而且可以根据需要扩展多个功能。避免了单独使用继承带来的“灵活性差”和“多子类衍生问题”。

2 、 Component 类在 Decorator 模式中充当抽象接口的角色，不应该去实现具体的行为。而且 Decorator 类对于 Component 类应该透明——换言之 Component 类无需知道 Decorator 类， Decorator 类是从外部来扩展 Component 类的功能。

3 、 Decorator 类在接口上表现为 is-a Component 的继承关系，即 Decorator 类继承了 Component 类所具有的接口。但在实现上又表现为 has-a Component 的组合关系，即 Decorator 类又使用了另外一个 Component 类。我们可以使用一个或多个 Decorator 对象来“装饰”一个 Component 对象，且装饰后的对象仍然是一个 Component 对象。（在这里我想谈一下我的理解：当我们实例化一个 Component 对象后，要给这个对象扩展功能，这时我们把这个 Component 对象当作参数传给 Decorator 的子类的构造函数——也就是扩展方法的功能类。对于引用类型传参时，实际上只是传递对象的地址，这样，在功能扩展是，操作的应该是同一个对象）

       GoF 《设计模式》中说到：将对象组合成树形结构以表示“部分 - 整体”的层次结构。 Composite 模式使得客户对单个对象和组合对象的使用具有一致性。

       Composite 组合模式结构如下：

       说道这，我觉得有一个编程中常见的场景，就是对于树的实现，很符合这个模式。下面我就用这个例子作一下。

       首先，我们先分析对于一棵树所包含的部分，树干、树枝、树叶，其中树干可以看成一个树枝（就是粗了点）。那么我们就应该有两种类实现 Leaf （树叶）和 Limb （树枝）。对于叶子节点和枝节点的不同在于枝节点有子树，而叶子节点没有子树。为了使单个对象和组合对象的使用具有一致性，我可以将叶子节点想象成没有子树的枝节点。这样我就可以得到一个抽象类，代码如下：

       public abstract class AbstractClass

    {

        public string name;

        public ArrayList list;

        public abstract void Add(AbstractClass item);       // 增加一个子节点

        public abstract void Remove(AbstractClass item);    // 去掉一个子节点

        public abstract string Print();                     // 打印当前节点

    }

       然后，我在对叶子节点和枝节点作不同的实现：

       枝节点：

       public class Limb:AbstractClass

    {

        public Limb()

        {

            list = new ArrayList();

        }

        public override void Add(AbstractClass item)

        {

            list.Add(item);

        }

        public override void Remove(AbstractClass item)

        {

            if(list.Contains(item))

                list.Remove(item);

        }

        public override string Print()

        {

            Console.Write(name + "\n");

            if(list.Count != 0)

            {

                for(int i = 0;i<list.Count;i++)

                {

                    Console.Write("(Parent is " + name + ")");

                    ((AbstractClass)list[i]).Print();

                }

            }

            return name;

        }

    }

    叶子节点：

    public class Leaf:AbstractClass

    {

        public Leaf()

        {

            list = null;

        }

        public override void Add(AbstractClass item)

        {

        }

        public override void Remove(AbstractClass item)

        {

        }

        public override string Print()

        {

            Console.Write(name + ",");

            return this.name;

        }

    }

    对于叶子节点来说，不需要子节点，当然也就不需要添加和删除子节点的方法。

    好，接下来，我们可以在客户程序中组建一棵树，来测试一下：

        static void Main(string[] args)

        {

            AbstractClass Tree = new Limb();

            GetTree(Tree);

            PrintTree(Tree);

            Console.Read();

        }

        public static void GetTree(AbstractClass Tree)

        {

            Tree.name = "1";

            AbstractClass leaf2 = new Leaf();

            leaf2.name = "2";

            Tree.Add(leaf2);

            AbstractClass limb3 = new Limb();

            limb3.name = "3";

            Tree.Add(limb3);

            AbstractClass leaf4 = new Leaf();

            leaf4.name = "4";

            limb3.Add(leaf4);

            AbstractClass leaf5 = new Leaf();

            leaf5.name = "5";

            limb3.Add(leaf5);

        }

        public static void PrintTree(AbstractClass Tree)

        {

            Tree.Print();

        }

    输出结果如下：

1

(Parent is 1)2,(Parent is 1)3

(Parent is 3)4,(Parent is 3)5,

在组织这个树时，的确能感觉到 GoF 《设计模式》中的那句话： 单个对象和组合对象的使用具有一致性。当然也的确感觉到一点矛盾：对于叶子节点来说，不需要 ArrayList 和 Add （） Remove （）应该不继承才对，当然如果在代码执行性能可以达到要求的情况下，简化一下编码实现复杂度也是挺好的一件事。

最后在来说说 Composite 组合模式的几个要点：

       1 、 Composite 模式采用树形结构来实现普遍存在的对象容器，从而将“一对多”的关系转化为“一对一”的关系，使得客户代码可以一致的处理对象和对象容器，无需关心处理的是单个对象，还是组合的对象容器。

2 、将“客户代码与复杂的对象容器结构”解耦是 Composite 模式的核心思想，解耦之后，客户代码将与纯粹的对象接口——而非对象容器的复杂内部实现结构——发生依赖关系，从而更能“应对变化”。

3 、 Composite 模式中，是将“ Add 和 Remove 的和对象容器相关的方法”定义在“表示抽象对象的 Component 类”中，还是将其定义在“表示对象容器的 Composite 类”中，是一个关乎“透明性”和“安全性”的两难问题，需要仔细权衡结构，这又是必须付出的代价。

4 、 Composite 模式在具体实现中，可以让父对象中的字对象反向追溯：如果父对象有频繁的遍历需求，可使用缓存技巧来改善效率

       《设计模式》中说到将抽象部分与实现部分分离，使他们可以独立的变化。

       举个例子更清楚些，好像我们平时玩的游戏中有 PS 版的，但是不是大家都有 PS 。这时我们等一段时间，一般会出 PC 版的或其他版本。由于支持游戏的平台不一样，但是如果我们编写的游戏程序为了适应另一种平台就要全部重新编写的话岂不是很麻烦。再加上游戏本身的变动，一句众人皆知的话：“死定了 ” 。

       现在我们来看看 Bridge 桥接模式，看看它是如何解决类似问题的，首先我们看看 Bridge 模式的结构。

       实际上，我们要做到的是把变化的部分提出，对其抽象，使变化独立。那我们如何做呢？通过组合的方式将变化独立出去。将一个事物中的多个纬度变化分离。

       下面举一个场景来理解一下，还是用汽车举例，我现在要一辆车（ BMW 或 BORA ）在路（ WaterRoad 或 Cement ）上跑。现在有两个纬度的变化点：汽车和路。也就是上图中的 AbstractChangePoint1 和 AbstractChangePoint2 。 AbstractChangePoint1 中包含有 AbstractChangePoint2 对象成员。。代码实现如下：

       abstract class AbstractCar

    {

        public AbstractRoad road;

        public AbstractCar(AbstractRoad road)

        {

            this.road = road;

        }

        public abstract string Run();

        public abstract string Stop();

    }

    abstract class AbstractRoad

    {

        public abstract string GetRoadType();

}

以汽车为变化中心，用组装的方式将两个变化点结合起来。使路的变化和汽车隔离。下面来编写路的实现。

class WaterRoad:AbstractRoad

    {

        public override string GetRoadType()

        {

            return "It is WaterRoad";

        }

 }

class CementRoad:AbstractRoad

    {

        public override string GetRoadType()

        {

            return "It is Cement";

        }

}

然后再来编写汽车的实现

class BMWCar:AbstractCar

    {

        public BMWCar(AbstractRoad road)

            : base(road)

        {

        }

        public override string Run()

        {

            return "BMW is running";

        }

        public override string Stop()

        {

            return "BMW is stopped";

        }

 }

class BROACar:AbstractCar

    {

        public BROACar(AbstractRoad road)

            : base(road)

        {

        }

        public override string Run()

        {

            return "BROA is running";

        }

        public override string Stop()

        {

            return "BROA is stopped";

        }

  }

然后我们在客户代码中调用这些类，首先，我想要这个场景是BMW在WaterRoad上跑，客户端代码如下：

static void Main(string[] args)

        {

            AbstractCar car = newBMWCar(newWaterRoad());

            Console.WriteLine(car.road.GetRoadType());

            Console.WriteLine(car.Run());

            Console.WriteLine(car.Stop());

            Console.Read();

        }

实现结果如下：

It is WaterRoad

BMW is running

BMW is stopped

如果我现在要一辆BORA在Cement上跑，我们只要稍微修改一下car的实例化就可以，代码如下：

static void Main(string[] args)

        {

            AbstractCar car = newBROACar(newCementRoad());

            Console.WriteLine(car.road.GetRoadType());

            Console.WriteLine(car.Run());

            Console.WriteLine(car.Stop());

            Console.Read();

     }

实现结果如下：

It is Cement

BROA is running

BROA is stopped

       最后我们再来说说 Bridge 模式的要点：

       1 、 Bridge 模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的纬度来变化。

2 、所谓抽象和实现沿着各自纬度的变化，即“子类化”它们，得到各个子类之后，便可以任意组合它们。

3 、 Bridge 模式有时候类似于多继承方案，但是多继承方案往往违背单一职责原则（即一个类只有一个变化的原因），复用性比较差。 Bridge 模式是比多继承方案更好的解决方法。

4 、 Bridge 模式的应用一般在“两个非常强的变化纬度”，有时候即使有两个变化的纬度，但是某个方向的变化纬度并不剧烈——换言之两个变化不会导致纵横交错的结果，并不一定要使用 Bridge 模式。

       《设计模式》中说道：将一个类的接口转换成客户希望的另一个接口。 Adapter 模式使得原本由于接口不兼容而不能一起工作的类可以一起工作。

       在实际的生活中有很多例子，如：我们常使用的移动硬盘，无论是笔记本硬盘还是台式机硬盘，对于数据的传输都不使用 Usb 的数据线，外接的硬盘盒就是将原来的硬盘数据传输方式适合 Usb 数据线。（哎，我那个硬盘盒买的时候还 190 元，其实一点都不值，整个一个盒，就那个转接芯片比较值钱，我说 50 ，人家不卖）。

       我再接着说适配器模式，先举个简单的代码例子，我现在要做一个队列的类，实现先进先出的功能。利用 ArrayList 对象。

       首先，我们先定义一些队列的接口，接口中定义队列的方法，代码如下：

       interface IQueue

    {

        void push(object item);     // 进队列

        object putout();            // 出队列

        object ShowLastItem();      // 返回队列中最后一项

        object ShowFirstItem();     // 返回队列中第一项

    }

    下面我们再来利用ArrayList对象实现一个队列：

    class Queue:IQueue

    {

        ArrayList adaptee;

        public Queue()

        {

            adaptee = new ArrayList();

        }

        public void push(object item)

        {

            adaptee.Add(item);

        }

        public object putout()

        {

            object item = adaptee[0];

            adaptee.RemoveAt(0);

            return item;

        }

        public object ShowLastItem()

        {

            return adaptee[adaptee.Count-1];

        }

        public object ShowFirstItem()

        {

            return adaptee[0];

        }

    }

    实现有了，现在用客户端程序调用来看一下结果：

    class Class1

    {

        /// <summary>

        /// 应用程序的主入口点。

        /// </summary>

        [STAThread]

        static void Main(string[] args)

        {

            Queue queue = new Queue();

            queue.push(1);

            queue.push(2);

            queue.push(3);

            queue.push(4);

            queue.push(5);

            Console.Write("FirstItem:" + queue.ShowFirstItem().ToString() + "\n");

            Console.Write("LastItem:" + queue.ShowLastItem().ToString() + "\n");

            Console.Write("output:" + queue.putout().ToString() + "\n");

            queue.push(6);

            Console.Write("FirstItem:" + queue.ShowFirstItem().ToString() + "\n");

            Console.Write("LastItem:" + queue.ShowLastItem().ToString() + "\n");

            Console.Read();

        }

    }

    输出结果：

    FirstItem:1

LastItem:5

output:1

FirstItem:2

LastItem:6

适配器模式实现有两种类型：对象适配器、类适配器。上面的代码是对象适配器方式。也就是适配器（Queue）中是使用被适配（ArrayList）的对象实现。它的结构如下：

    Gof 《设计模式》中提到了两种Adapter适配器模式，一种叫对象适配器模式，另一种叫类适配器模式。对象适配器模式的结构如上图，也就是我刚才举的那个例子，那什么是类适配器模式呢？实际上类适配器模式就是让Adapter的实现继承Adaptee。换句话说：类适配器模式是以继承的方式来实现，而对象适配器模式是以组合的方式实现。以前我们说过：继承增加了模块间的耦合程度，而组合降低了耦合程度，所以有人建议多使用对象适配器模式，少用类适配器模式。不过既然提到，我也具体谈谈类适配器模式。它的结构如下图：

    我们依然用上面的那个队列的例子，首先我们要实现一个Adapter的类，这个类要继承适配对象Adaptee类，也就是例子中的ArrayList，还有队列接口，就是我们定义的IQueue，代码如下：

    class ClassAdapter:ArrayList,IQueue

    {

        public ClassAdapter()

        {

        }

        public void push(object item)

        {

            this.Add(item);

        }

        public object putout()

        {

            object item = this[0];

            this.RemoveAt(0);

            return item;

        }

        public object ShowLastItem()

        {

            return this[this.Count-1];

        }

        public object ShowFirstItem()

        {

            return this[0];

        }

    }

    然后我们再修改一下客户代码：

        static void Main(string[] args)

        {

            ClassAdapter queue = new ClassAdapter();

            queue.push(1);

            queue.push(2);

            queue.push(3);

            queue.push(4);

            queue.push(5);

            Console.Write("FirstItem:" + queue.ShowFirstItem().ToString() + "\n");

            Console.Write("LastItem:" + queue.ShowLastItem().ToString() + "\n");

            Console.Write("output:" + queue.putout().ToString() + "\n");

            queue.push(6);

            Console.Write("FirstItem:" + queue.ShowFirstItem().ToString() + "\n");

            Console.Write("LastItem:" + queue.ShowLastItem().ToString() + "\n");

            Console.Read();

        }

    输出结果为：

FirstItem:1

LastItem:5

output:1

FirstItem:2

LastItem:6

要说明一点：从实现的代码看：ClassAdapter类同时继承了ArrayList,IQueue，这样违反了设计原则中的单一职责原则（SRP）——一个类应该仅有一个引起他变化的原因。

接下来，我们在看看Adapter模式的几个要点：

1、              Adapter 模式主要应用于“希望服用一些现存的类，但是接口又与复用环境要求不一致的情况”，在遗留代码复用、类库迁移等方面非常有用。

2、              Gof23 定义了两种Adapter模式的实现结构：对象适配器和类适配器。但类适配器采用“多继承”的实现方式，带来了不良的高耦合，所以一般不推荐使用。对象适配器采用“对象组合”的方式，更符合松耦合精神。

3、              Adapter 模式本身要求我们尽可能的使用“面向接口的编程”风格，这样才能在后期很方便的适配

Adapter 模式的实现方法有很多，说到这我在举一个例子，我现在有这样一个场景。我有一辆BORA车子和BMW的Engine和Wheel，我现在想改装这辆BORA使其拥有BMW的Engine和Wheel，我如何做呢？

首先，我们要拥有一些BMW的零部件，代码如下：

class BMWPartClass

    {

        public void BMWEngine()

        {

            Console.Write("It is a BMWEngine\n");

        }

        public void BMWWheel()

        {

            Console.Write("It is a BMWWheel\n");

        }

}

然后，再来实现对这些零部件的适配，代码如下：

interface ITarget

    {

        void Request();

    }

    class Adapter:ITarget

    {

        BMWPartClass adaptee = new BMWPartClass();

        public void Request()

        {

            adaptee.BMWEngine();

            adaptee.BMWWheel();

        }

}

对于我的BORA的实现：

class MyBORAClass

    {

        public void Process(ITarget target)

        {

            target.Request();

        }

}

最后是客户端代码：

static void Main(string[] args)

        {

            MyBORAClass bora = new MyBORAClass();

            bora.Process(new Adapter());

            Console.Read();

    }

输出结果是：

It is a BMWEngine

It is a BMWWheel