设计模式之结构模式

一 Facade模式

 

    外观模式（Facade pattern）涉及到子系统的一些类。所谓子系统，是为提供一系列相关的特征（功能）而紧密

 

关联的一组类。例如，一个Account类、Address类和CreditCard类相互关联，成为子系统的一部分，提供在线客户

 

的特征。在真实/的应用系统中，一个子系统可能由很多类组成。子系统的客户为了它们的需要，需要和子系统中的

 

一些类进行交互。客户和子系统的类进行直接的交互会导致客户端对象和子系统（Figure1）之间高度耦合。任何

 

的类似于对子系统中类的接口的修改，会对依赖于它的所有的客户类造成影响。外观是一个能为子系统和客户提供

 

简单接口的类。当正确的应用外观，客户不再直接和子系统中的类交互，而是与外观交互。外观承担与子系统中类

 

交互的责任。实际上，外观是子系统与客户的接口，这样外观模式降低了子系统和客户的耦合度.

 

二 Proxy模式

 

    代理模式通过使用代理来替代实际的对象，使程序能够控制对该对象的访问，同时解耦了调用者对实际对象的依

 

赖.在jive中，就使用了大量的代理模式，象对论坛等对象的访问都是通过代理进行的，在代理中，加入了对原始对

 

象的权限控制。使得结构更清晰。代理负责权限控制，实际对象负责业务逻辑。java中代理分为静态和动态，具体

 

参见http://blog.csdn.net/cz_hyf/archive/2006/10/30/1357164.aspx

 

三 Adapter模式

 

    我们经常碰到要将两个没有关系的类组合在一起使用,第一解决方案是：修改各自类的接口，但是如果我们没有

 

源代码，或者，我们不愿意为了一个应用而修改各自的接口。 怎么办? 使用Adapter，将一个类的接口转换成客户

 

希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

 

    这里的Adapter与GUI中事件Adapter是有所区别的，那个是为了省去程序员写监听者时避免实现监听器全部方法

 

的一种手段。

 

四 composite模式

 

    composite完美地实现了“树”这一现实实体在OO软件世界的映射。此模式巧妙之处在于，树叶和枝干实现了同一

 

接口，但树干同时是装载该接口实现类实例的容器，树干可以容纳树叶、同时也可以再容纳树干，于是，一棵数

 

就完美地被描绘出来了。一个比较典型的例子就是，界面上的Panel是容器的同时、也是控件，可以容纳控件的

 

同时也可以再容纳容器（这里说得就比较罗嗦了，容器本身就是控件嘛）。

 

 Composite使用的好处:

 

1.使客户端调用简单，客户端可以一致的使用组合结构或其中单个对象，用户就不必关系自己处理的是单个对象

 

还是整个组合结构，这就简化了客户端代码。

2.更容易在组合体内加入对象部件. 客户端不必因为加入了新的对象部件而更改代码。

 

由于要用到遍历，composite模式一般使用Iterator模式，对于要用到复杂递归的算法，可以考虑是否能用

 

composite模式来简化。

 

四 Decorator模式

 

   我们通常可以使用继承来实现功能的拓展,如果这些需要拓展的功能的种类很繁多,那么势必生成很多子类,增加

 

系统的复杂性,同时,使用继承实现功能拓展,我们必须可预见这些拓展功能,这些功能是编译时就确定了,是静态的.

使用Decorator的理由是:这些功能需要由用户动态决定加入的方式和时机.Decorator提供了"即插即用"的方法,

在运行期间决定何时增加何种功能。

    在java中，包装时，将变成以下这样：decorator = new decorator(decoratee)。decoratee是被包装者。

一般来说，decorator和decoratee实现同样的接口，在decorator中，可以提供decoratee的同名方法，并且在

 

这个方法中，除了调用decoratee的同名方法以外，还做一些额外的事情。

 

    jive的过滤器是decorator模式的典型使用，最初的forummessage是一个decoratee,经过某个过滤器包装后，

 

就成了decorator,这个decorator还可以作为下个过滤器的decoratee。这样，运行时根据forum的不同动态决定要

 

使用多少次decorator包装，每次都进行不一样的过滤。最终完成所有的过滤功能。

 

    假设现在要返回的是最终包装后的message的getsubject()方法。它会针对包装层层剥离进取调用。即它会先

 

调用decoratee的getSubject方法。然后进行过滤处理后返回处理后的message。同样decoratee很可能也是一个

 

decorator这样，又会去调用里面的getSubject()方法，然后做过滤。这种调用思维是逆向的，真正的调用

 

要反过来是：第一个decoratee的getSubject()方法返回后，用第一个过滤器进行过滤操作，然后结果送给第二个

 

过滤器过滤，直至完成所有过滤。

 

    具体可参见《java实用系统开发指南》之过滤器与装饰模式。

 

五 Bridge模式

 

    Bridge模式将抽象和行为划分开来,各自独立,但能动态的结合。在面向对象设计的基本概念中，对象这个概念

 

实际是由属性和行为两个部分组成的，属性我们可以认为是一种静止的，是一种抽象，一般情况下，行为是包含在

 

一个对象中，但是，在有的情况下，我们需要将这些行为也进行归类，形成一个总的行为接口，这就是桥模式的用

处。

 

    Bridge模式是一个在实际系统中经常应用的模式。它最能体现设计模式的原则针对接口进行编程，和使用聚合

 

不使用继承这两个原则。

 

    Bridge模式是解决多重继承的根本原因。如果你在实现应用中一个类，需要继承两个以上的类，并且这两者之

 

间又持有某种关系，它们两个都会有多种变化。Bridge模式是把这两个类，分解为一个抽象，一个行为，使它们两

 

个分离，这样两种类都可以独立的变化。他们之间可以通过聚合来达到关联的目的。

 

    如一杯咖啡为例，分为大杯和中杯，不管是大杯还是中杯，都是一种抽象，可以定义一个抽象类来表示咖啡，

 

具体是大杯还是中杯可以通过继承实现。除此之外，还有加奶与不加奶之分，这是一种行为，可以定义一种总行为

 

接口（或者抽象类），具体的行为实现（继承）了总行为接口(抽象类)。抽象和行为之间通过聚合来达到关联的目

的。

 

六 FlyWeight模式

 

    当系统的许多类拥有相同内容的小类时，为了节省内存,可以使大家共享一个类(元类).这就是flyweight模式。