创建模式之 学习总结

下文转自：http://hi.baidu.com/sanlng/blog/item/b186f4c88bfd86167f3e6fac.html

创建型设计模式是用来解决对象的创建问题。经典二十三种设计模式中，被划分到创建型设计模式中的有：

●单件模式

●抽象工作模式

●工厂方法模式

●生成器模式

●原型模式

每一种模式都代表一种应用场合，也有通常的代码结构，但在学习中如果只注重理解代码结构而忽略或轻视其应用场合，那对设计模式的理解很可能会走上“歧途”，因为代码只是最终的表现形式。理解和掌握设计模式的关键在于理解与把握其应用场合，相较而言，代码结构是次要的。那么创建型的这些设计模式在应用场合上有什么不同呢？

一、单件模式的应用场合

单件模式在理解时比较轻松，因为“单件”的字面可能已经表现出了它的应用场合。如果你要控制一个类在整个应用程序中被实例化的次数，那么这时候就可以使用单件。“单件”不一定指某个类只能被实例化一次，这只是通常的应用场合，你完全可以控制某个类被实例化两次或更多次，关键在于这样做是否有意义。

二、工厂方法与抽象工厂

这两种设计模式比较容易被搞混，因为两者在应用场合与代码结构上都有相似之处。这里我们就需要知道，这两种设计模式最主要的不同点在什么地方。工厂方法与抽象工厂都是用来创建对象的，不同之处在于，工厂方法是用来创建一个对象，而抽象工厂则是用来创建一系列对象的（这些对象是相关的），在代码结构上，抽象工厂要比工厂方法复杂一些。如果从代码结构上去区别这两种设计模式，那很容易发生混乱，所以说，与其通过理解代码结构来理解设计模式，不如通过设计模式的应用场合来区分它们。

三、生成器模式

生成器模式与工厂方法和抽象工厂在代码结构上也有类似之处，尤其与抽象工厂的相似性更多一些，特别是当把生成器模式与工厂方法模式结合到一块的时候，很容易会被认为是抽象工厂。生成器模式是用来创建一个复杂的对象，这个复杂的对象通常由许多子对象按一定的规则组合而成，这与抽象工厂不同。抽象工厂是创建一组相关对象，关键就在于这一组相关对象与生成器模式的一系子对象有什么不同。对生成器模式而言，构成其表示的子对象缺一不可，而抽象厂的一组相关对象则不具有这样的要求，这就是区别。它们的关系可以这样理解，汽车不能缺少轮胎（生成器模式），而一个具体的游戏场景中，可以不存在汽车（抽象工厂）。

四、原型模式

原型设计模式是利用对象的克隆技术来创建新对象。这里有隐匿含的一点，那就是如何处理“原型”对象的状态。如何通过克隆而创建出来的新对象与原型对象具体不同的或是根本没有状态（在新对象刚被创建出的那一时刻），那这里可能就是不原形设计模式了。因为原型设计模式一个重要的重点在于，原型对象与新对象在被创建出的那一时刻要具有相同的状态，说白了就是新对象与原型对象要在某种状态间保持一致，（比如你以一个男人为原型而克隆了一个人，那克隆出来的人应该也是男人（例子不当），只是这个人的个头比原来的人高。）然后根据需要去设置新对象的那些特别的属性，这一点，我们可以称其为“状态保持”。

在我们使用设计模式的时候，有一点要时刻注意，那就是不要“刻意”的去应用设计模式。设计模式的选择与应用，决定于你要解决和处理的问题。并且同一问题可能可以使用不同的设计模式去解决，这里需要我们衡量，因为设计模式的应用是有代价的。

在理解设计模式时，我们也要认识到，设计模式在很大程度是其实就是一种经验的传承（解决某种问题的经验），经验不等同真理(真理也是一定范围内的)，所以不要认为所有设计模式的设计模式都是百分百有效的。包括上面我们讨论一切，离开特定的场合，都有可能是错误的。

 

下文转自：http://www.winu.cn/space-14160-do-blog-id-25159.html

到今天为止把创建型的几种设计模式算是学完了,搞一段落.进行一下总结.

时间比较短,还好创建型的比较简单,以后估计不会这么顺利了.由于没有真正的实践在项目中,所以到现在为止,我认为我还没有掌握,仅仅是对设计模式有些了解而已.

人家说英语是说出来的,所以我也把我知道的关于创建型的设计模式的相关知识总结出来,供大家参考和讨论,希望能与各位同仁共同进步.

 

创建型模式,主要用来解决new所带来的对象间的耦合关系,除了singleton和prototype之外,都需要使用factory来负责对象的实例化，prototype是通过原型（也就是抽象）来克隆对象。

 

白话一点儿说，创建型模式就是把有可能经常变化的对象单独拎出来处理，使这些经常变化的部分在发生变化时不会影响整个系统。

 

GOF设计模式有5种是创建模式.

其中Singleton模式用来控制对象创建的个数,一般是一个,可以通过变化创建指定数量的对象.

 

factory method模式是最最基础的创建型模式，也是最基础的设计模式之一。既然是面向对象编程，当然要创建对象。factory method模式就是解决了对象的基本创建问题。对象通过自己的工厂创建实例，在创建点不依赖具体实现而仅仅依赖于对象自己的抽象。编译时只知道要创建哪种对象（抽象），运行时才知道具体会创建这种对象的哪个对象。反正一种对象的行为都是相似的，所以抽象也是一样的。只是具体实现不同。比如车都能转弯，只是摩托车和汽车转弯的具体实现不同，但抽象是相同的。这里编译时只说车要转弯，在运行时再具体告诉程序是哪个车要转弯。

 

abstract factory模式是在factory method模式的基础上发展而来， factory method模式只解决了创建哪个对象的问题，而abstract factory解决了创建哪个系列对象的问题。这一系列对象之间可能有很多关联和交互。白话点而说就是，比如我们肯定都用床上用品，包括床单，被罩和枕巾等。我们不会一辈子都用一套吧，肯定要换洗的，有坏的还得换新的（这里假设整套整套坏/换）。那么abstract factory就用上了。一次创建一套床上用品，不用修改任何地方，只需要增加新的床单类，被罩类和枕巾类，然后在调用时告诉系统，我要用这个新的。就OK了，符合了面向对象的对修改关闭对扩展开放的原则。

 

builder模式与factory method一样，都是创建一个对象。但是它却是创建了一个超级复杂的对象。它可以让我们通过相同的创建过程创建出不同的表示。在这里，创建对象的算法是稳定的，但是对象的各个部分却是不稳定的，经常会变。比如要建造一个房子，建造房子的过程，比如打地基，搭架子，垒砖这些骨干的过程是不变的，这是稳定的算法。但是在造门和窗户的时候却有可能经常发生变化。有可能这个房子要用A工厂的门，那个房子却要用B工厂的门。这是就要用到builder模式了。不管你用谁的门，但是造出来的肯定得是房子。

 

prototype模式诠释了面向对象的依赖倒置原则。当一个Manager对象依赖某个具体实现时，我们把这个实现抽象出来（前提是这个对象是易变的），使Manager对象依赖于这个抽象，这样，以后扩展新的基于这个抽象的实现就会easy了。而manager里通过抽象的克隆创建需要数量的对象。这样，manager只依赖抽象。我想这也是我们提倡面向接口编程的原因。

 

总之，创建型模式解决了软件设计中对象创建的问题，通常，往往是我们遇到了易变类，才会使用创建型模式，至于使用哪种，就要看易变类和系统的特性了。