设计模式备忘 - 创建型

工厂模式

工厂模式主要是为创建对象提供过渡接口，以便将创建对象的具体过程屏蔽隔离起来，达到提高灵活性的目的。当客户程序不需要知道要使用对象的创建过程，或者客户程序使用的对象存在变动的可能或根本就不知道使用哪一个具体的对象，就可以使用工厂模式。该模式具体分为三类：

 

简单工厂模式（Simple Factory）

简单工厂模式又称静态工厂方法模式。它存在的目的很简单：定义一个用于创建对象的接口。具体组成包括工厂类角色，抽象产品角色和具体产品角色。

 

不足：对于新产品的加入，工厂类是很被动的。实际应用中，很可能产品是一个多层次的树状结构，而在简单工厂模式中只有一个工厂类来对应这些产品。

 

工厂方法模式（Factory Method）

工厂方法模式去掉了简单工厂模式中工厂方法的静态属性，使得它可以被子类继承。这样在简单工厂模式里集中在工厂方法上的压力可以由工厂方法模式里不同的工厂子类来分担。具体组成包括抽象工厂角色，具体工厂角色，抽象产品角色和具体产品角色。

 

不足：在工厂方法模式中，要么将判断逻辑留在抽象工厂角色中，要么在客户程序中将具体工厂角色写死。而且产品对象创建条件的改变必然会引起工厂角色的修改。

 

抽象工厂模式（Abstract Factory）

抽象工厂模式的用意为:给客户端提供一个接口，可以创建多个产品族中的产品对象，其具体组成与工厂方法一样。

 

单例模式（Singleton）

单例模式是为了保证一个类仅有一个实例，并提供一个访问它的全局访问点。单例模式中的“单例”通常用来代表那些本质上具有唯一性的系统组件或资源，比如文件系统、资源管理器等等。单例模式可分为有状态的和无状态的。有状态的单例对象一般也是可变的单例对象，多个单态对象在一起就可以作为一个状态仓库一样向外提供服务。没有状态的单例对象也就是不变单例对象，仅用做提供工具函数。具体实现包括：

 

饿汉式

//直接定义静态成员变量的实例
private static Singleton instance = new Singleton();

 

懒汉式

public static synchronized Singleton getInstance() {
    if (instance == null) instance = new Singleton();
    return instance;
}

 

注册表单例

以上两种实现方式均失去了多态性，不允许被继承。还有另外一种灵活点的实现，将构造函数设置为受保护的，这样允许被继承产生子类。这种方式在具体实现上又有所不同，可以将父类中获得对象的静态方法放到子类中再实现，也可以在父类的静态方法中进行条件判断来决定获得哪一个对象。在GOF中认为最好的一种方式是维护一张存有对象和对应名称的注册表。

public class Singleton {
    static private Singleton s = new Singleton();
    private static HashMap sinRegistry = new HashMap();

    protected Singleton() {}
    public static Singleton getInstance(String name) {
        if (name == null) name = "Singleton";
        if (sinRegistry.get(name) == null) {
            try {
                sinRegistry.put(name , Class.forName(name).newInstance());
            } catch(Exception e) {}
        }
        return (Singleton) (sinRegistry.get(name));
    }
}

public class SingletonChild extends Singleton {
    protected SingletonChild() {}
    public static SingletonChild getInstance() {
        return (SingletonChild1)Singleton.getInstance("SingletonChild");
    }
}

 

不足：在有多个虚拟机或多个类加载器时，可能会产生多个单例对象。在使用上面介绍的懒汉式单例模式时，同步处理的恰当与否也是至关重要的。不然可能会达不到得到单个对象的效果，还可能引发死锁等错误。为了使一个单例类变成可串行化的，仅仅在声明中添加“implements Serializable”是不够的。因为一个串行化的对象在每次返串行化的时候，都会创建一个新的对象，而不仅仅是一个对原有对象的引用。为了防止这种情况，可以在单例类中加入readResolve方法。

 

建造模式（Builder）

将构造复杂对象的过程和组成对象的部件解耦。就像攒电脑一样，不管什么品牌的配件，只要兼容就可以装上。同样，一样的配件，可以有好多组装的方式。这是对降低耦合、提高可复用性精神的一种贯彻。建造模式可以对复杂产品的创建进行更加精细的控制。产品的组成是由指导者角色调用具体建造者角色来逐步完成的，所以比起其它创建型模式能更好的反映产品的构造过程。

 

其与工厂模式的区别在于：创建模式着重于逐步将组件装配成一个成品并向外提供成品，而抽象工厂模式着重于得到产品族中相关的多个产品对象。

 

当要生成的产品有复杂的内部结构，而系统中对此产品的需求将来可能要改变产品对象的内部结构的构成，而且不能将产品的内部构造完全暴露给客户程序，一是为了可用性，二是为了安全等因素。满足上面的设计环境就可以考虑使用建造模式。其具体组成包括：

 

抽象建造者角色 ：这个角色用来规范产品对象的各个组成成分的建造。一般而言，此角色独立于应用程序的业务逻辑。
具体建造者角色 ：担任这个角色的是于应用程序紧密相关的类，它们在指导者的调用下创建产品实例。这个角色在实现抽象建造者角色提供的方法的前提下，达到完成产品组装，提供成品的功能。

指导者角色 ：调用具体建造者角色以创建产品对象。指导者并没有产品类的具体知识，真正拥有产品类的具体知识的是具体建造者对象。
产品角色 ：建造中的复杂对象。它要包含那些定义组件的类，包括将这些组件装配成产品的接口。

 

以下是Bruce Eckel在《Think in Patterns with Java》中用的例子：

//不同的媒体形式
class Media extends ArrayList {}
class Book extends Media {}
class Magazine extends Media {}
class WebSite extends Media {}

// 进而包含不同的媒体组成元素
class MediaItem {
    private String s;
    public MediaItem(String s) { this.s = s; }
    public String toString() { return s; }
}

class Chapter extends MediaItem {
    public Chapter(String s) { super(s); }
}

class Article extends MediaItem {
    public Article(String s) { super(s); }
}

class WebItem extends MediaItem {
    public WebItem(String s) { super(s); }
}

// 抽象建造者角色,它规范了所有媒体建造的步骤:
class MediaBuilder {
    public void buildBase() {}
    public void addMediaItem(MediaItem item) {}
    public Media getFinishedMedia() { return null; }
}

//具体建造者角色
class BookBuilder extends MediaBuilder {
    private Book b;
    public void buildBase() {
        System.out.println("Building book framework");
        b = new Book();
    }
    public void addMediaItem(MediaItem chapter) {
        System.out.println("Adding chapter " + chapter);
        b.add(chapter);
    }
    public Media getFinishedMedia() { return b; }
}

class MagazineBuilder extends MediaBuilder {
    private Magazine m;
    public void buildBase() {
        System.out.println("Building magazine framework");
        m = new Magazine();
    }
    public void addMediaItem(MediaItem article) {
        System.out.println("Adding article " + article);
        m.add(article);
    }
    public Media getFinishedMedia() { return m; }
}

//指导者角色,也叫上下文
class MediaDirector {
    private MediaBuilder mb;
    public MediaDirector(MediaBuilder mb) {
        this.mb = mb; //具有策略模式相似特征的
    }
    public Media produceMedia(List input) {
        mb.buildBase();
        for(Iterator it = input.iterator(); it.hasNext();)
            mb.addMediaItem((MediaItem) it.next());
        return mb.getFinishedMedia();
     }
}

 

原型模式（Prototype）

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。在Java中提供了clone()方法来实现对象的克隆，所以Prototype模式实现变得简单许多。其具体组成包括：

 

客户角色 ：让一个原型克隆自己来得到一个新对象。

抽象原型角色 ：实现了自己的clone方法，扮演这种角色的类通常是抽象类，且它具有许多具体的子类。
具体原型角色 ：被复制的对象，为抽象原型角色的具体子类。

 

该模式最简单的使用方式：

//先new一个具体原型角色作为样本
Prototype p = new ConcretePrototype();

//使用原型p克隆出一个新对象p1
Prototype p1 = (Prototype) p.clone();

 

更进一步，可以通过运用工厂模式添加一个原型管理器，因此将创建原型角色、拷贝原型角色和客户程序分离开来。

//使用原型管理器后,客户获得对象的方式
Prototype p1 = PrototypeManager. getManager().getPrototype(“ConcretePrototype”);

 

不足：原型模式主要的缺陷就是每个原型必须含有clone方法，在已有类的基础上来添加clone操作是比较困难的。而且当内部包括一些不支持copy或者循环引用的对象时，实现就更加困难了。