不知道怎么样，等一下看看

http://www.iteye.com/topic/376865

原型模式其实是从一个对象再创建另个一个可定制的对象，

而且不需知道任何创建的细节。

一般在初始化的信息不发生变化的情况下，克隆是最好的办法。

既隐藏了对象创建的细节，又对性能是大大的提高。

相当于不用重新初始化对象，而是动态地获得对象运行时的状态。

浅复制与深复制

如果字段是值类型的， 则对该字段执行逐位复制，

如果字段是引用类型，则复制引用但不复制引用的对象，因此，原始对象

及其复本引用同一对象。



浅复制：被复制对象的所有变量都含有与原来的对象相同的值，

而所有的对其他对象的引用都仍然指向原来的对象。



另一种需求：把要复制的对象所引用的对象都复制一遍。



深复制：深复制把引用对象的变量指向复制过的新对象，而不原有的被引用的对象。



--------------------------------------------------------------------------

模板方法模式

既然用了继承，并且肯定这个继承有意义，就应该要成为子类的模板，所有重复的

代码都应该要上升到父类去，而不是证每个子类都 去重复。"

当我们要完成在某一细节层次一致的一个过程或一系列步骤，但其个别步骤在更详细

的层次上的实现可能不同时，我们通常考虑用模板方法模式来处理。

模板方法模式是通过把不变行为搬移到超类，去除子类中的重复代码来体现它的优势。



模板方法模式就是提供了一个很好的代码复用平台。



当不变的和可变的行为在方法的子类实现中混合在一起的时候，不变的行为就会在子类中

重复出现。我们通过模板方法械把这些行为搬移到单一的地方，这样就帮助了类摆脱重复的不变行为的纠缠。



--------------------------------------------------------------------------------

迪米特法则（最少知识原则）：

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。

如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

在类的结构设计上，每一个类都应当尽量降低成员的访问权限。

迪米特法则其根本思想，是强调了类之间的松耦合。

类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类

造成波及。

--------------------------------------------------------------------------------

外观模式：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，

这个接口使得这一子系统更加容易使用。

首先， 在设计初期阶段，应该要有意识的将不同的两个层分离，

层与层之间建立外观Facade,这样可以为复杂的子系统提供一个简单的接口，使得耦合

大大降低。其次，在开发阶段，子系统往往因为不断的重构演化而变得越来越复杂。增加外观Facade可以提供一个简单的接口，减少它们之间的依赖。第三，在维护一个遗留的大型

系统时，可能这个系统已经非常难以维护和扩展了。

为新系统开发一个外观Facade类，来提供设计粗糙或高度复杂的遗留代码的比较清晰简单的接口，让新系统与Facade对象交互，Facade与遗留代码交互所有复杂的工作。

--------------------------------------------------------------------------------

建造者模式：

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

如果我们用了建造者模式，那么用户就只需指定需要建造的类型就可以得到它们，

而具体建造过程和细节就不需知道了。

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

builder是为创建一个Product对象的各个部件指定的抽象接口。ConcreteBuilder是什么呢?

对的，它是具体建造者，实现Builder接口，构造和装配各个部件。

Director指挥者,它是构建一个使用Builder接口的对象.

该模式主要是用于创建一些复杂的对象，这些对象内部构建间的建造顺序通常是稳定的，

但对象内部的构建通常面临着复杂的变化。

建造者模式的好处就是使得建造代码与表示代码分离，由于建造者隐藏了该产品是如何组装的，所以若需要改变一个产品的内部表示，只需要再定义一个具体的建造者就可以了。

建造者模式是在当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时适用的模式。



----------------------------------------------------------------------------------


观察者模式又叫做发布-订阅(Publish/Subscribe)

模式

观察者模式定义了一种一对多的依赖关系，让多个

观察者对象

同时监听某一个主题对象。这个主题对象在状态发

生变化时，会通知所有观察对象，使它们能够自动

更新自己。

将一个系统分割成一系列相互协作的类有一个很不好的副作用，那就是需要维护相关对象

间的一致性。我们不希望为了维持一致性而使各类紧密耦合，这样会给维护，扩展和重用都带来不便

当一个对象的改变需要同时改变其他对象的时候就需要用到观察者模式。

而且它不知道具体有多少对象有待改变时，应该考虑使用观察者模式，还有吗？

一个抽象模型有两个方面，其中一方面依赖于另一方面，这时用观察者模式可以将

这两者封装在独立的对象中使它们各自独立地改变和复用。



观察者模式所做的工作其实就是在解除耦合。让耦合的双方都依赖于抽象，而不是依赖

于具体，从而使得各自的变化都不会影响另一边的变化。



------------------------------------------------------------------------

工厂方法模式

定义一个用于创建对象的接口，让子类

决定实例化哪一个类。

抽象工厂模式

抽象工厂模式Abstract Factory,

提供一个创建一系列相关或相互依赖对象的接口，

而无需要指定它们具体的类。

通常是在运行时刻再创建一个具体工厂类的实例，这个具体的工厂再创建

具有特定实现的产品对象，也就是说， 为创建不同的产品对象，客户端应使用不同

的具体工厂。

在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常

容易，它只需要改变具体工厂即可使用不同的产品配置。



它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操纵实例，

产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。

编程是门艺术，这样大批量的改动，显然是非常丑陋的做法。

一个程序员如果从来没有熬夜写程序的经历，不能算是一个好程序员，因为他没有

痴迷过，所以他不会有大成就。

面向对象设计其实就是希望做到代码的责任分解。

---------------------------------------------------------------------------

状态模式：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其

类。状态模式主要解决的是当控制一个对象状态转换的条件表达式过于复杂时的情况。

把状态的判断逻辑转移到表示不同状态的一系列类当吕，可以把复杂的判断逻辑简化。

将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。

将特定的状态相关的行为都放入一个对象中，由于所有与状态相关的代码都存在于某个

ConcreteState中，所以通过定义新的子类可以很容易地增加新的状态和转换。

消除庞大的条件分支语句。来减少相互间的依赖

当一个对象的行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，

就可以考虑使用状态模式了。

-------------------------------------------------------------------

适配器模式

将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原来由于接口

不兼容而不能一起工作的那些类可以一起工作。

系统的数据和行为都正确，但接口不符时，我们应该考虑用适配器，目的是使控制

范围之外的一个原有对象与某个接口匹配。适配器模式主要应用于希望复用一些现存的

类，但是接口又与复用环境要求不一致的情况，

使用一个已经存在的类，但如果它的接口，也就是它的方法和你的要求不相同时，

就应该考虑用适配器模式

两个类所做的事情相同或相似，但是具有不同的接口时要使用它。

客户代码可以统一调用同一接口就行了，可以更简单，更直接，更紧凑。

在双方都不太容易修改的时候再使用适配器模式适配。

事后控制不如事中控制，事中控制不如事前控制。