三、Flyweight模式的构成：

Flyweight模式一般由几个部分组成：

·Flyweight接口(抽象类) ：定义了一个可共享的元类
·Flyweight实现类：实现了元类中的操作，而且可能会提供一个用于保存内部状态(共享属性)的空间
·Flyweight Factory：创建Flyweight的工厂类，创建后将其保存到Flyweight Pool中
·Flyweight Pool：缓冲Flyweight对象的池，通常包含在工厂类中


四、Flyweight模式的简单实现

1.Flyweight:

package com.pattern.flyweight2;

public abstract class Flyweight
{
    public abstract void operation();
}

2.ConcreateFlyweight:

package com.pattern.flyweight2;

public class ConcreateFlyweight extends Flyweight
{
    private Object key;

    public ConcreateFlyweight(Object key)
    {
        this.key = key;
    }

    @Override
    public void operation()
    {
        System.out.println("key:" + key);
    }

}

package com.pattern.flyweight2;

import java.util.Hashtable;

@SuppressWarnings("unchecked")
public class FlyweightFactory
{
　//Flyweight pool
    private Hashtable flyweights = new Hashtable();

    public Flyweight getFlyweight(Object key)
    {
        Flyweight flyweight = null;
        if(flyweights.containsKey(key))
        {
            flyweight = (Flyweight) flyweights.get(key);
        }
        if (!flyweights.containsKey(key))
        {
            flyweight = new ConcreateFlyweight(key);
            flyweights.put(key, flyweight);
        }
        return flyweight;
    }
    
    public int getFlyweightsSize()
    {
        return flyweights.size();
    }
}

package com.pattern.flyweight2;

public class Client
{
    private Flyweight f1 = null;
    private Flyweight f2 = null;
    private Flyweight f3 = null;
    private Flyweight f4 = null;
    FlyweightFactory factory = new FlyweightFactory();

    public Client()
    {
        f1 = factory.getFlyweight("baidu");
        f2 = factory.getFlyweight("google");
        f3 = factory.getFlyweight("baidu");
        f4 = factory.getFlyweight("google");
    }

    public void show()
    {
        f1.operation();
        f2.operation();
        f3.operation();
        f4.operation();
        System.out.println(factory.getFlyweightsSize());
    }

    public static void main(String[] args)
    {
        Client client = new Client();
        client.show();
    }
}

       为子系统中的一组接口提供一个统一接口。Facade模式定义了一个更高层的接口，使子系统更加容易使用。

       大致意思是说：使用一种比原有方式更简单的办法与系统交互。例如，我们把一个很文件的文件，放在了第二抽屉里，而第二个抽屉的钥匙放在了第一个抽屉里，我们要想取出这个文件，第一步肯定要拿到第一个抽屉的钥匙，然后打开它再拿出第二个抽屉的钥匙，最后打开第二个抽屉取出文件。

       我就上面说的那个情形写一下实现代码，首先我们要实现二个子系统,呵呵，把抽屉比喻成系统，有点夸张了（DrawerOne、DrawerTwo）：

class DrawerOne {

    public void open(){

       System.out.println("第一个抽屉被打开了");

       getKey();

    }

    public void getKey(){

       System.out.println("得到第二个抽屉的钥匙");

    }

}

class DrawerTwo{

    public void open(){

       System.out.println("第二个抽屉被打开了");

       getFile();

    }

    public void getFile(){

       System.out.println("得到这个重要文件");

    }

}

public class Client{

    public static void main(String []args){

       DrawerOne darwerOne=new DrawerOne();

       DrawerTwo darwerTwo=new DrawerTwo();

       darwerOne.open();

       darwerTwo.open();

    }

}

由于没有使用Façade模式，可以看到要想得到这个文件要首先打开第一个抽屉，然后再打开第二个抽屉，在我们实际所开发的系统中，有时候客户要实现某一操作，并不需要知道实现这一操作的详细步骤，而是简单地点击某一个按钮就可以得到自己想要的结果。下面对上面的代码使用Façade模式进行改进，建立一个FacadeDrawer类：

class DrawerFacade{

    DrawerOne darwerOne=new DrawerOne();

    DrawerTwo darwerTwo=new DrawerTwo();

    public void open(){

       darwerOne.open();

       darwerTwo.open();

    }

}

修改Client类：

public class DrawerClient{

    public static void main(String []args){

       DrawerFacade drawer=new DrawerFacade();

       drawer.open();

    }

}

输出结果如下：

第一个抽屉被打开了

得到第二个抽屉的钥匙

第二个抽屉被打开了

得到这个重要文件

正如上面所说，客户端client，它并不需要关心子系统，而是关心DrawerFacade所留下来的和外部交互的接口，而子系统在DrawerFacade的聚合。

以上只是个人拙见，哪里有不正确的地方，希望大家多多批评指正。^_^

    Facade模式主要适用于以下几种情况:

1)    不需要使用一个复杂系统的所有功能，而且可以创建一个新的类，包含访问系统的所有规则。如果只需要使用系统的部分功能，那么你为新类所创建的API将比原系统的API简单的多。

2)    希望封装或者隐藏系统原系统。

3)    希望使用原系统的功能，而且还希望增加一些新的功能。

4)    编写新类的成本小于所有人学会使用或者未来维护原系统上所需的成本。

如何使用? 因为Java中的提供clone()方法来实现对象的克隆,所以Prototype模式实现一下子变得很简单.

以勺子为例：

package com.pattern.prototype;

/** *//**
 * 原型类(以汤匙为例) ,注意要实现Cloneable接口
 * 
 * @author zdw
 * 
 */
public abstract class AbstractSpoon implements Cloneable
{
    public String spoonName;

    public String getSpoonName()
    {
        return this.spoonName;
    }

    public void setSpoonName(String spoonName)
    {
        this.spoonName = spoonName;
    }

    /** *//**
     * 重写clone()方法
     */
    @Override
    public Object clone()
    {
        try
        {
            return super.clone();
        } catch (CloneNotSupportedException e)
        {
            System.out.println("此对象不支持复制");
        }
        return null;
    }
}

package com.pattern.prototype;

/** *//**
 * 给原型对象赋值
 * 
 * @author zdw
 * 
 */
public class SoupSpoon extends AbstractSpoon
{
    public SoupSpoon()
    {
        setSpoonName("chinaDrong");
    }
}

package com.pattern.prototype;

/** *//*******************************************************************************
 * 测试类
 * 
 * @author zdw
 * 
 */
public class Client
{
    public static void main(String[] args)
    {
        AbstractSpoon spoon = new SoupSpoon();
        System.out.println(spoon.getSpoonName());
        // 通过对象的clone()方法,即可获得对象的一个copy.
        AbstractSpoon spoon2 = (AbstractSpoon) spoon.clone();
        System.out.println(spoon2.getSpoonName());
    }
}

当然也可以结合工厂模式来创建AbstractSpoon实例。

在Java中Prototype模式变成clone()方法的使用，由于Java的纯洁的面向对象特性，使得在Java中使用设计模式变得很自然，两者已经几乎是浑然一体了。这反映在很多模式上，如Interator遍历模式。

       除了咖啡以为，Central Perk还提供丰富的调味品，比如：炼乳、巧克力、砂糖、牛奶等，而且这些调味品也是要单独按份收费的，所以调味品也是订单系统中重要的一部分。

       于是，考虑到调味品的管理，开发者又有了下面这样的类结构：

       上面的情况绝对是不能容忍的，于是开发者们经过讨论，又提出了下面的设计方案件：

       看上去似乎这是一个不错的设计，那么下面我们再来给Beverage增加子类，如下图所示：

 

       基类的cost()方法将计算所有调味品的价钱(当然是只包括布尔值为true的调味品)，子类里的cost()方法将扩展其功能，以包含特定类型饮料的价钱。

       OK! 现在我们似乎已经有了一个看上去还不错的设计，那么Central Perk的这个记账系统就按这个设计来实现就万事大吉了吗？等一下，还是让我们先从以前学习过的“找到系统中变化的部分，将变化的部分同其它稳定的部分隔开。”这个设计原则出发，重新推敲一下这个设计。

那么对于一家咖啡店来说，都有那些变化点呢？调味品的品种和价格会变吗？咖啡的品种和价格会变吗？咖啡和调味品的组合方式会变吗？YES!对于一家咖啡店来说，这些方面肯定会经常发生改变的！那么，当这些改变发生的时候，我们的记账系统要如何应对呢？ 如果调味品发生改变，那么我们只能从代码的层次重新调整Beverage基类，这太糟糕了；如果咖啡发生改变，我们可以增加或删除一个子类即可，这个似乎还可以忍受；那么咖啡和调味品的组合方式发生改变呢？如果顾客点了一杯纯黑咖啡外加两份砂糖和一份巧克力，或者顾客点了一杯脱咖啡因咖啡(Decaf)外加三份炼乳和一份砂糖呢？我倒！突然意识到，上面的设计根本不支持组合一份以上同种调味品的情况，因为基类里的布尔值只能记录是否包含某种调味品，而并不能表示包含几份，连基本的功能需求都没有满足，看来这些开发者可以卷铺盖滚蛋了！(似乎他们改行去做炸弹更合适！)

       好吧！让我们来接手这个设计！我们已经分析了前面设计的失败之处，我们应该实现支持调味品的品种和价格任意改变而不需要修改已有代码的设计；我们还要实现支持咖啡品种和价格任意改变而不需要修改已有代码的设计(这点上面的设计通过继承算是实现了)；还有就是支持咖啡和调味品的品种和份数任意组合而不需要修改已有代码的设计；还有就是代码重用越多越好了，内聚越高越好了，耦合越低越好了；(还有最重要的，报酬越高越好啦！)

       看来我们要实现的目标还真不少，那么我们到底该怎么做呢？说实话，我现在也不知道！我们需要先去拜访一下今天的主角—装饰者模式，看看她能给我们带来什么惊喜吧！

这就是装饰者模式

我们还是先看一下官方的定义：

The Decorator Pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. (装饰者模式可以动态地给一个对象增加其他职责。就扩展对象功能来说，装饰者模式比生成子类更为灵活。)

这里我们要重点注意那个dynamically（动态的），什么是动态？静态又是什么？这是我们要重点区分的地方，后面我们还会专门讨论这个问题。下面先看看装饰者模式的类图和顺序图：

l         定义对象的接口，可以给这些对象动态增加职责；

ConcreteComponent（具体被装饰对象）

l         定义具体的对象，Decorator可以给它增加额外的职责；

Decorator（装饰者抽象类）

l         维护一个指向Component实例的引用，并且定义了与Component一致的接口；

ConcreteDecorator（具体装饰者）

l         具体的装饰对象，给内部持有的具体被装饰对象增加具体的职责；

我们先来说说上面提到的动态和静态的问题，所谓动态是说可以在系统运行时(RunTime)动态给对象增加其它职责而不需要修改代码或重新编译；所谓静态是说必须通过调整代码(DesignTime)才能给对象增加职责,而且系统还需要重新编译；从具体技术层面来说，对象的组合和继承正好对应于前面的动态和静态，因为通过对象组合建立的交互关系不是在代码中(DesignTime)固定死的，而是在运行时(RunTime)动态组合的；而通过继承建立的关系是僵硬的难以改变的，因为它是在代码中(DesignTime)固定死了的，根本不存在运行时(RunTime)改变的可能。换个角度说：我们应该多使用对象组合来保持系统的运行时扩展性，尽量少使用继续，因为继承让程序变得僵硬！这句话听着是不是很熟悉啊？恩！这就是我们前面文章里提过多次的一个设计原则：Favor composition over inheritance.（优先使用对象组合，而非类继承），更多的就不需要再解释了吧？

       那么回到装饰者模式，跟前面介绍过的模式一样，装饰者同样是一个很简单的模式，特别是画出类图和顺序图之后，一切都很清楚明了。这里只有一个地方需要特殊强调一下：Decorator是装饰者模式里非常特殊的一个类，它既继承于Component【IS A关系】,又维护一个指向Component实例的引用【HAS A关系】，换个角度来说，Decorator跟Component之间，既有动态组合关系又有静态继承关系，WHY? 这里为什么要这么来设计？上面我们说过，组合的好处是可以在运行时给对象增加职责，Decorator【HAS A】Component的目的是让ConcreteDecorator可以在运行时动态给ConcreteComponent增加职责，这一点相对来说还比较好理解；那么Decorator继承于Component的目的是什么？在这里，继承的目的只有一个，那就是可以统一装饰者和被装饰者的接口，换个角度来说，不管是ConcretComponent还是ConcreteDecorator，它们都是 Component，用户代码可以把它们统一看作Component来处理，这样带来的更深一层的好处就是，装饰者对象对被装饰者对象的功能职责扩展对用户代码来说是完全透明的，因为用户代码引用的都是Component，所以就不会因为被装饰者对象在被装饰后，引用它的用户代码发生错误，实际上不会有任何影响，因为装饰前后，用户代码引用的都是Component类型的对象，这真是太完美了！装饰者模式通过继承实现统一了装饰者和被装饰者的接口，通过组合获得了在运行时动态扩展被装饰者对象的能力。

我们再举个生活中的例子，俗话说“人在衣着马在鞍”，把这就话用装饰者模式的语境翻译一下，“人通过漂亮的衣服装饰后，男人变帅了，女人变漂亮了；”。对应上面的类图，这里人对应于ConcreteComponent,而漂亮衣服则对应于ConcreteDecorator；换个角度来说，人和漂亮衣服组合在一起【HAS A】，有了帅哥或美女，但是他们还是人【IS A】，还要做人该做的事情，但是可能会对异性更有吸引力了(扩展功能)！    

       现在我们已经认识了装饰者模式，知道了动态关系和静态关系是怎么回事，是时候该解决咖啡店的问题了，从装饰者模式的角度来考虑问题，咖啡和调味品的关系应该是：咖啡是被装饰对象而调味品是装饰者，咖啡和调味品可以任意组合，但是不管怎么组合，咖啡还是咖啡！原来这么简单啊！具体看下面的类图：

      该模式以对客户端透明的方式扩展对象的功能。

2、涉及角色
      抽象构件角色：定义一个抽象接口，来规范准备附加功能的类。

      具体构件角色：将要被附加功能的类，实现抽象构件角色接口。

      抽象装饰者角色：持有对具体构件角色的引用并定义与抽象构件角色一致的接口。

      具体装饰角色：实现抽象装饰者角色，负责为具体构件添加额外功能。

 
  3、简单实现
抽象构件角色java 代码:

package com.pattern.decorator2;
/** *//**
 * 抽象构件角色
 * @author zdw
 *
 */
public interface Component
{
    //默认方法A
    void functionA();
}

package com.pattern.decorator2;
/** *//**
 * 具体构件角色
 * @author zdw
 *
 */
public class ConcreateComponent implements Component
{
    
    public void functionA()
    {
        System.out.println("Function A");
    }

}

package com.pattern.decorator2;

/** *//**
 * 抽象装饰者角色
 * 
 * @author zdw
 * 
 */
public class Decorator implements Component
{
    //抽象构件角色的引用
    private Component component;
    
    public Decorator(Component component)
    {
        this.component = component;
    }

    public void functionA()
    {
        component.functionA();
    }

}

package com.pattern.decorator2;
/** *//**
 * 具体装饰者角色
 * @author zdw
 *
 */
public class ConcreateDecorator1 extends Decorator
{
    public ConcreateDecorator1(Component component)
    {
        super(component);
    }

    @Override
    public void functionA()
    {
        super.functionA();
        this.functionB();
    }
    //根据自己的需要扩展
    private void functionB()
    {
        System.out.println("function B");
    }
}

package com.pattern.decorator2;

public class ConcreateDecorator extends Decorator
{
    public ConcreateDecorator(Component component)
    {
        super(component);
    }

    @Override
    public void functionA()
    {
        super.functionA();
        this.functionC();
    }

    private void functionC()
    {
        System.out.println("fucntion C");
    }
}

package com.pattern.decorator2;

/** *//**
 * 测试客户端
 * 
 * @author zdw
 * 
 */
public class Client
{

    /** *//**
     * @param args
     */
    public static void main(String[] args)
    {
        // 一层套一层，进行方法组合
        Component component = new ConcreateDecorator(new ConcreateDecorator1(
                new ConcreateComponent()));
        component.functionA();
    }

}

OO原则：动态地将责任附加到对象上。想要扩展功能，装饰者提供有别于继承的另一种选择。

要点：
1、继承属于扩展形式之一，但不见得是达到弹性设计的最佳方案。
2、在我们的设计中，应该允许行为可以被扩展，而不须修改现有的代码。
3、组合和委托可用于在运行时动态地加上新的行为。
4、除了继承，装饰者模式也可以让我们扩展行为。
5、装饰者模式意味着一群装饰者类，这些类用来包装具体组件。
6、装饰者类反映出被装饰的组件类型（实际上，他们具有相同的类型，都经过接口或继承实现）。
7、装饰者可以在被装饰者的行为前面与/或后面加上自己的行为，甚至将被装饰者的行为整个取代掉，而达到特定的目的。
8、你可以有无所数个装饰者包装一个组件。
9、装饰者一般对组建的客户是透明的，除非客户程序依赖于组件的具体类型。
10、装饰者会导致设计中出现许多的小对象，如果过度使用，会让程序变得很复杂。

当不需要全部实现适配器接口提供的方法时，可先设计一个抽象类实现适配器接口，并为接口中每个方法提供一个默认实现（空方法）。那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求。

二、结构

三、动机

对于一个接口不想使用其所有的方法时。


我觉得把Default Adapter模式和Adapter模式割裂开来，不会影响对Default Adapter模式的理解。
Default Adapter模式就是为目标接口提供一个平庸实现层，真正的实现类从此平庸实现层继承，Override其中对自己有意义的方法，而其他方法保持其平庸状态。
为Target接口所需的方法统统提供一套缺省实现，通常的做法是，除非你特别要求，否则我什么都不做。
如果实现类比较多而且需要实现的方法很多、真正做事儿的方法很少，那么Default Adapter模式会为系统省下不少重复代码。

缺省适配器模式：为一个接口提供缺省实现，这样子类型可以从这个缺省实现进行扩展，而不必从原有接口进行扩展。
“平庸化”的适配器模式。

package com_pattern_deafultadapter;

/** *//**
 * 接口(提供一些要使用的方法)
 * @author zdw
 *
 */
public interface AbstraceService
{
    public void method1();

    public void method2();

    public void mehtod3();
}

package com_pattern_deafultadapter;

/** *//*******************************************************************************
 * 缺省适配器类
 * 
 * @author zdw
 * 
 */
public class ServiceAdaper implements AbstraceService
{
    public void method1()
    {
    }

    public void method2()
    {
    }

    public void mehtod3()
    {
    }
}

package com_pattern_deafultadapter;

/** *//*******************************************************************************
 * 真正要使用方法的类
 * 
 * @author zdw
 * 
 */
public class ConcreateService extends ServiceAdaper
{
    // 重写自己需要的方法
    @Override
    public void method1()
    {
    }
}

在很多操作中，比如建立目录 数据库连接都需要这样的单线程操作。

还 有, singleton能够被状态化; 这样，多个单态类在一起就可以作为一个状态仓库一样向外提供服务，比如，你要论坛中的帖子计数器，每次浏览一次需要计数，单态类能否保持住这个计数，并且 能synchronize的安全自动加1，如果你要把这个数字永久保存到数据库，你可以在不修改单态接口的情况下方便的做到。

另外方面，Singleton也能够被无状态化。提供工具性质的功能，

Singleton模式就为我们提供了这样实现的可能。使用Singleton的好处还在于可以节省内存，因为它限制了实例的个数，有利于Java垃圾回收（garbage collection）。

我们常常看到工厂模式中类装入器(class loader)中也用Singleton模式实现的,因为被装入的类实际也属于资源。

如何使用?
一般Singleton模式通常有几种形式:

第二种形式:

使用Singleton.getInstance()可以访问单态类。

上面第二中形式是lazy initialization，也就是说第一次调用时初始Singleton，以后就不用再生成了。

注意到lazy initialization形式中的synchronized，这个synchronized很重要，如果没有synchronized，那么使用getInstance()是有可能得到多个Singleton实例。关于lazy initialization的Singleton有很多涉及double-checked locking (DCL)的讨论，有兴趣者进一步研究。

一般认为第一种形式要更加安全些。

使用Singleton注意事项：
有时在某些情况下，使用Singleton并不能达到Singleton的目的，如有多个Singleton对象同时被不同的类装入器装载；在EJB这样的分布式系统中使用也要注意这种情况，因为EJB是跨服务器，跨JVM的。

我们以SUN公司的宠物店源码(Pet Store 1.3.1)的ServiceLocator为例稍微分析一下：

在Pet Store中ServiceLocator有两种，一个是EJB目录下；一个是WEB目录下，我们检查这两个ServiceLocator会发现内容差不 多，都是提供EJB的查询定位服务，可是为什么要分开呢？仔细研究对这两种ServiceLocator才发现区别：在WEB中的 ServiceLocator的采取Singleton模式，ServiceLocator属于资源定位，理所当然应该使用Singleton模式。但是 在EJB中，Singleton模式已经失去作用，所以ServiceLocator才分成两种，一种面向WEB服务的，一种是面向EJB服务的。

Singleton模式看起来简单，使用方法也很方便，但是真正用好，是非常不容易，需要对Java的类 线程 内存等概念有相当的了解。

总之：如果你的应用基于容器，那么Singleton模式少用或者不用，可以使用相关替代技术。

GOF《设计模式》一书对Adapter模式是这样描述的：
   将一个类的接口转换成客户希望的另外一个接口。Adapter模式使原本由于接口不兼容而不能一起工作的类可以一起工作。

图解 :

    这段话大致是说：我们需要一种方式，为一个功能正确但接口不合的对象创建一个新接口。例如，客户给我们如下需求：

1） 为都有“显示”(display)行为的点、线、正方形分别创建类。

2） 客户对象不必知道自己到底拥有点、线、还是正方形。它只需知道拥有这些形状中的一个。

也就是说，我们要用一个更高层次的概念将这些具体形状都涵盖进去，这个高层概念可以称为：“可显示的形状”。因此，我们需要创建一个接口Shape:

interface Shape{

    publicvoid display();

}

现在客户忽然间有让我们给这个系统增加一个画圆的功能。这个看起来很简单，只需定义一个Circle类来实现Shape接口，但是我们要给它编写display方法，这可不是件简单的事，假如此时我们正好发现一个XXCircle类，它有一个方法刚好可以完成这个功能，那么有没有更好的方法来利用它呢，这时我们就要用到Adapter模式了。XXCircle代码如下：

class XXCircle{

    public void displayCircle(){

       System.out.println("通过XXCircle.displayCircle()画圆");

    }

}

    Adapter模式有两种类型：

1)    对象Adapter模式，它依赖于一个对象（适配器）包含另一个对象(被适配的对象)。

class CircleObject implements Shape{

    public XXCircle circle;

    public CircleObject(XXCircle xxcircle){

    circle=xxcircle;

    }

    public void display() {

       circle.displayCircle(); 

    }

}

public class Client {

    public static void main(String[] args) {

       XXCircle circle=new XXCircle();

       CircleObject co=new CircleObject(circle);

       co.display();

    }

}

2)     类Adapter模式，它是通过多重继承来实现的（java中没有多继承，是通过接口来实现的）。

class CircleClass extends XXCircle implements Shape{

    public void display() {

       super.displayCircle();  

    }

}

public class Client {

    public static void main(String[] args) {

       CircleClass cc=new CircleClass();

       cc.display();

    }

}

    小结：Adapter模式是一个很常用的模式，它将一个（或多个）类的接口转换成我们需要类所具备的一个接口。它的实现方式是：创建一个具备所需接口的类，然后包装原有类的方法，这样实际上就包含了被适配的对象。它主要适用于以下几种情况：

1） 你希望使用他人编写的子程序或方法，因为你需要它所执行的功能。

2） 你无法将这个子程序直接加入程序中。

3） 子程序的接口或调用方式与需要使用它的相关对象不完全相同。

1 透明式

 添加Component对象的操作定义在Component角色中，这样的话不仅Composite需要实现这些方法，Leaf也需要实现这些方法，
 而这些方法对于Leaf来说没有任何意义，不过将系统实现统一起来了，因此对用户来说透明（用户无需区分Composite还是Leaf）
 ，因为这些角色中都具备这些方法。
 
2 安全式

 添加Component对象的操作定义在Composite角色中，这样的话Leaf就无需实现这些方法（因为Leaf本身根本不需要实现这些方法）

安全式的实现:

1.抽象角色:

package com.composite;
/** *//***
 * 抽象角色
 * @author zdw
 *
 */
public interface Component
{
    void doAction();
}

2.叶子角色:

package com.composite;

/** *//**
 * 叶子角色
 * 
 * @author zdw
 * 
 */
public class Leaf implements Component
{

    @Override
    public void doAction()
    {
        System.out.println("Leaf do Action");
    }

}

3.Comosite角色

package com.composite;

import java.util.ArrayList;
import java.util.List;

/** *//**
 * Composite角色
 * 
 * @author zdw
 * 
 */
public class Composite implements Component
{
    private List<Component> list = new ArrayList<Component>();

    public void addComponent(Component component)
    {
        if (!list.contains(component))
        {
            list.add(component);
        }
    }

    public void removeComonent(Component component)
    {
        if (list.contains(component))
        {
            list.remove(component);
        }
    }

    public List<Component> getAllComponents()
    {
        return list;
    }

    @Override
    public void doAction()
    {
        for (Component com : list)
        {
            com.doAction();
        }
    }

}

现在写个测试类来测试:

package com.composite;

public class Client
{
    public static void main(String[] args)
    {
        Component leaf1 = new Leaf();
        Component leaf2 = new Leaf();

        Composite composite = new Composite();
        composite.addComponent(leaf1);
        composite.addComponent(leaf2);
        composite.doAction();
    }
}

对于透明模式只需要把add()或remove等方法,写个抽象角色接口里面就行了.

void add();
void remove();

Command模式是最让我疑惑的一个模式,我在阅读了很多代码后,才感觉隐约掌握其大概原理,我认为理解设计模式最主要是掌握起原理构造,这样才 对自己实际编程有指导作用.Command模式实际上不是个很具体,规定很多的模式,正是这个灵活性,让人有些confuse.

Command定义
n 将来自客户端的请求传入一个对象，无需了解这个请求激活的 动作或有关接受这个请求的处理细节。

这是一种两台机器之间通讯联系性质的模式，类似传统过程语 言的 CallBack功能。

优点：
解耦了发送者和接受者之间联系。 发送者调用一个操作，接受者接受请求执行相应的动作，因为使用Command模式解耦，发送者无需知道接受者任何接口。

不少Command模式的代码都是针对图形界面的,它实际就是菜单命令,我们在一个下拉菜单选择一个命令时,然后会执行一些动作.

将 这些命令封装成在一个类中,然后用户(调用者)再对这个类进行操作,这就是Command模式,换句话说,本来用户(调用者)是直接调用这些命令的,如菜 单上打开文档(调用者),就直接指向打开文档的代码,使用Command模式,就是在这两者之间增加一个中间者,将这种直接关系拗断,同时两者之间都隔 离,基本没有关系了.

显然这样做的好处是符合封装的特性,降低耦合度,Command是将对行为进行封装的典型模式,Factory是将创建进行封装的模式,
从Command模式,我也发现设计模式一个"通病":好象喜欢将简单的问题复杂化, 喜欢在不同类中增加第三者,当然这样做有利于代码的健壮性 可维护性 还有复用性.

如何使用?
具体的Command模式代码各式各样,因为如何封装命令,不同系统,有不同的做法.下面事例是将命令封装在一个Collection的List中,任何 对象一旦加入List中,实际上装入了一个封闭的黑盒中,对象的特性消失了,只有取出时,才有可能模糊的分辨出:

按照通常做法,我们就可以直接调用这三个Command,但是使用Command模式,我们要将他们封装起来,扔到黑盒子List里去:

这三个命令进入List中后,已经失去了其外表特征,以后再取出,也可能无法分辨出谁是Engineer 谁是Programmer了,看下面客户端如何调用Command模式:

由此可见,调用者基本只和接口打交道,不合具体实现交互,这也体现了一个原则,面向接口编程,这样,以后增加第四个具体命令时,就不必修改调用者TestCommand中的代码了.

理解了上面的代码的核心原理,在使用中,就应该各人有自己方法了,特别是在如何分离调用者和具体命令上,有很多实现方法,上面的代码是使用"从List过一遍"的做法.这种做法只是为了演示.

使用Command模式的一个好理由还因为它能实现Undo功能.每个具体命令都可以记住它刚刚执行的动作,并且在需要时恢复.

Command模式在界面设计中应用广泛.Java的Swing中菜单命令都是使用Command模式,由于Java在界面设计的性能上还有欠缺,因此界面设计具体代码我们就不讨论,网络上有很多这样的示例.