纵横谈23种面向对象的设计模式--创建型

工厂方法模式：提供一个简单的决策类，根据条件生成产品。

抽象工厂模式：提供一个创建并返回一系列产品的接口。

单件模式：某个类只能有一个实例。

提供一个全局访问点。

（可拓展到有限个实例）生成器模式：将一个复杂对象的构建于呈现分开，以便根据不同需要创建不同的形式。

原型模式：先实例化一个类，然后克隆或者拷贝该类来构建新的实例。

可以用共有方法进一步修改这些实例。

难点：生成器模式关注于将构造对象的过程和构造的各个部分分开，而抽象工厂关注于构建一个产品系列。

实际上，最大的区别是生成器模式创建的产品不一定有共同的父类，只要有类似的构造过程即可。

实际上我们常见到的文件资源管理器的实现完全可以使用生成器模式。

简单工厂、工厂模式与生成器模式对比：工厂模式变化点在于新增对象（客户在需要创建新对象的时候，只需要新建一个工厂去继承工厂父类就可以了），而生成器模式在于构建复杂对象的表示（客户在需要创建这个复杂对象的时候，只需要给指导者一个具体的创建者就可以了），变化点完全不同，那么其应用场景自然不同。

如果非要霸王硬上弓的用，那么就需要改动模式构建，例如，生成器模式若要完成新增对象的功能，那么它就可能产生两个不同的builder基类。

这是完全不推荐的。

那简单工厂属于静态工厂，根据传入参数决定需要创建哪种对象，它的扩展性也不好。

Prototype模式同工厂模式，同样对客户隐藏了对象的创建工作，但是，与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的，达到了"隔离类对象的使用者和具体类型（易变类）之间的耦合关系"的目的。

此外引入Prototype模式后不再需要一个与具体产品等级结构平行的工厂方法类，减少了类的构造。

总之，根据不同的应用场景（即不同的变化），选择合适的模式才是王道。

什么叫合适，即变化都可以像配件那样直接装配到系统中，无须改动系统其它部分，系统会自动检测到新增配件，并通过客户程序或者配置文件进行选择。

简单工厂模式：专门定义一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类。

它又称为静态工厂方法模式，属于类的创建型模式。

简单工厂模式的实质是由一个工厂类根据传入的参数，动态决定应该创建哪一个产品类（这些产品类继承自一个父类或接口）的实例。

意图：提供一个类，由它负责根据一定的条件创建某一具体类的实例角色及其职责：•工厂（Creator）角色：简单工厂模式的核心，它负责实现创建所有实例的内部逻辑。

工厂类可以被外界直接调用，创建所需的产品对象。

•抽象（Product）角色：简单工厂模式所创建的所有对象的父类，它负责描述所有实例所共有的公共接口。

•具体产品（Concrete Product）角色：简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。

一般来讲它是抽象产品类的子类，实现了抽象产品类中定义的所有接口方法。

模式的特点:•优点：简单工厂模式的创建目标，所有创建的对象都是充当这个角色的某个具体类的实例。

在这个模式中，工厂类是整个模式的关键所在。

它包含必要的判断逻辑，能够根据外界给定的信息，决定究竟应该创建哪个具体类的对象。

用户在使用时可以直接根据工厂类去创建所需的实例，而无需了解这些对象是如何创建以及如何组织的。

有利于整个软件体系结构的优化。

•缺点：体现在其工厂类上，由于工厂类集中了所有实例的创建逻辑，所以"高内聚"方面做的并不好。

另外，当系统中的具体产品类不断增多时，可能会出现要求工厂类也要做相应的修改，扩展性并不很好。

工厂方法模式：工厂方法模式的对简单工厂模式进行了抽象。

有一个抽象的Factory类（可以是抽象类和接口），这个类将不在负责具体的产品生产，而是只制定一些规范，具体的生产工作推延到其子类去完成。

意图：定义一个用户创建对象的接口，让子类决定实例化哪一个类，工厂方法模式使一个类的实例化延迟到其子类。

优点：实现了开闭原则，可以在不改变工厂的前提下增加新产品。

实现要点：•Factory Method模式的两种情况：一是Creator类是一个抽象类且它不提供它所声明的工厂方法的实现；二是Creator是一个具体的类且它提供一个工厂方法的缺省实现。

•工厂方法是可以带参数的。

•工厂的作用并不仅仅只是创建一个对象，它还可以做对象的初始化，参数的设置等。

效果：•用工厂方法在一个类的内部创建对象通常比直接创建对象更灵活。

•Factory Method模式通过面向对象的手法，将所要创建的具体对象的创建工作延迟到了子类，从而提供了一种扩展的策略，较好的解决了这种紧耦合的关系。

适用性：•当一个类不知道它所必须创建的对象的类的时候。

•当一个类希望由它的子类来指定它所创建的对象的时候。

•当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。

附注：•基类是一个抽象类，模式必须返回一个完整的可工作的类•基类包含默认方法，除非这些默认方法不能胜任才调用子类方法•可以讲参数传递给工厂，告诉工厂返回哪一个类。

抽象工厂模式：提供创建对象的接口。

与工厂方法类似，但此处返回的一系列相关产品。

实现过程同样推延到子系列类去实现。

与工厂方法的区别在于他们的层次模型。

工厂方法的抽象基类只有儿子，而抽象工厂模式却是有孙子，而且每个儿子的儿子们之间有相互关联依赖关系。

意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

角色及职责：•抽象工厂（Abstract Factory）：声明生成一系列抽象产品的方法•具体工厂（Concrete Factory）：执行生成一系列抽象产品的方法，生成一系列具体的产品•抽象产品（Abstract Product）：为这一系列的某一种产品声明接口•具体产品（Product）：定义具体工厂生成的具体产品的对象，实现产品接口•客户（Client）：我们的应用程序客户端（不要理解成人），使用抽象产品和抽象工厂生成对象。

附注：简单工厂、工厂方法、抽象工厂比较简单工厂，工厂方法，抽象工厂都属于设计模式中的创建型模式。

其主要功能都是帮助我们把对象的实例化部分抽取了出来，优化了系统的架构，并且增强了系统的扩展性。

•简单工厂：简单工厂模式的工厂类一般是使用静态方法，通过接收的参数的不同来返回不同的对象实例。

不修改代码的话，是无法扩展的。

•工厂方法：工厂方法是针对每一种产品提供一个工厂类。

通过不同的工厂实例来创建不同的产品实例。

在同一等级结构中，支持增加任意产品。

•抽象工厂：抽象工厂是应对产品族概念的。

比如说，每个汽车公司可能要同时生产轿车，货车，客车，那么每一个工厂都要有创建轿车，货车和客车的方法。

应对产品族概念而生，增加新的产品线很容易，但是无法增加新的产品。

小结：•工厂模式中，重要的是工厂类，而不是产品类。

产品类可以是多种形式，多层继承或者是单个类都是可以的。

但要明确的，工厂模式的接口只会返回一种类型的实例，这是在设计产品类的时候需要注意的，最好是有父类或者共同实现的接口。

使用工厂模式，返回的实例一定是工厂创建的，而不是从其他对象中获取的。

工厂模式返回的实例可以不是新创建的，返回由工厂创建好的实例也是可以的。

区别：•简单工厂：用来生产同一等级结构中的任意产品。

（对于增加新的产品，无能为力）•工厂模式：用来生产同一等级结构中的固定产品。

（支持增加任意产品）•抽象工厂：用来生产不同产品族的全部产品。

（对于增加新的产品，无能为力；支持增加产品族）以上三种工厂方法在等级结构和产品族这两个方向上的支持程度不同。

所以要根据情况考虑应该使用哪种方法。

单件模式：保证某个类有且仅有一个实例。

意图：单件模式保证应用只有一个全局惟一的实例，并且提供一个访问它的全局访问点。

结构：包括防止其他对象创建实例的私有构造函数、保存惟一实例的私有变量和全局访问接口等。

效果：单件提供了全局惟一的访问入口，因此易于控制可能发生的冲突。

单件是对类静态函数的一种改进，首先它避免了全局变量对系统的污染；其次正常类可以有子类，可以定义虚函数，具有多态性。

而类中的静态方法是不能定义为虚函数的，因此不具有多态性。

单件模式可以扩展为多件，即允许有受控的多个实例存在。

适用场合：当类只能有一个实例存在，并且可以在全局访问时。

这个惟一的实例应该可以通过子类实现扩展，并且用户无须更改代码即可使用。

我们前面介绍的工厂类经常被实例化为全局惟一的单件，可能的单件还有管理日志的对象、关键字生成对象和外部设备接口对象等。

实现：•私有构造函数防止在外部实例化。

•保存惟一实例的静态的私有变量。

•初始化并获得惟一实例的静态方法。

比较：•与全局变量的比较：单件模式维护自身的实例化，在使用时是安全的。

一个全局对象无法自行维护，也就无法避免重复创建多个实例，系统资源会被大量占用。

更糟糕的是在很多情况下会出现逻辑问题，当这些对象访问相同的资源（例如串口时）时，会发生访问冲突。

•与实用类静态方法的比较：实用类提供系统公用的静态方法，并且也经常采用私有化的构造函数。

与单件不同，它没有实例，其中的方法全部是静态方法。

（1）实用类不保存状态，仅提供功能。

（2）实用类不具有多态性，而单件可以有子类。

（3）单件是对象，实用类只是方法的集合。

实现：•简单实现public sealed class Singleton{static Singleton instance=null;Singleton(){}public static Singleton Instance{get{if (instance==null){instance = new Singleton();}return instance;}}}这种方式的实现对于线程来说并不是安全的，因为在多线程的环境下有可能得到Singleton类的多个实例。

如果同时有两个线程去判断（instance == null），并且得到的结果为真，这时两个线程都会创建类Singleton 的实例，这样就违背了Singleton模式的原则。

实际上在上述代码中，有可能在计算出表达式的值之前，对象实例已经被创建，但是内存模型并不能保证对象实例在第二个线程创建之前被发现。

该实现方式主要有两个优点：•由于实例是在 Instance 属性方法内部创建的，因此类可以使用附加功能（例如，对子类进行实例化），即使它可能引入不想要的依赖性。

•直到对象要求产生一个实例才执行实例化；这种方法称为"惰性实例化"。

惰性实例化避免了在应用程序启动时实例化不必要的 singleton。

•安全的线程public sealed class Singleton{static Singleton instance=null;static readonly object padlock = new object();Singleton(){}public static Singleton Instance{get{lock (padlock){if (instance==null){instance = new Singleton();}return instance;}}}}这种方式的实现对于线程来说是安全的。