大话设计模式宏观把控

       大话设计模式是我们现在学习的一个重头戏……本来看完C#视频之后，什么都不懂，但看了设计模式书的附录之后，真的感觉瞬间柳暗花明的赶脚呀！现在让我们先来全局的看一下这本书……

本书通过一些幽默的小例子，以大鸟和小菜对话的方式，主要讲了模式和原则，不得不用一句俗语说：真是生动形象呀！

      我把这些模式根据其特点，分成了创建型模式、结构型模式和行为型模式。

     模式：

1、策略模式（Strategy）：义了算法家族，分别封装起来，让它们之间可以互相替换，此模式让算法的变化，不会影响到使用算法的客户。（商场打折促销的例子）

2、装饰模式（Decorator）：动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。（小菜打扮约会的例子）

优点：把类中的装饰功能从类中搬移去除，简化原有的类。即有效的把类的核心职责和装饰功能区分开了，而且可以去除相关类中重复的装饰逻辑。

缺点：需要注意装饰模式中的顺序。

3、代理模式（Proxy）：为其他对象提供一种代理以控制对这个对象的访问。（为别人做嫁衣的例子）

优点：就是在访问对象时引入一定程度的间接性，由于这种间接性，可以附件多种用途。

代理分类：

远程代理：为一个对象在不同的地址空间提供局部代表。这样可以隐藏一个对象存在于不同地址空间的事实。

虚拟代理：根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真实对象。

安全代理：用来控制真实对象访问时的权限。

智能指引：当调用真实的对象时，代理处理另外一些事。

4、工厂方法模式（FactoryMethod）：定义一个用于创建对象的接口，让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。（学习雷锋做好事的例子）

优点：克服了简单工厂违背开放—封闭原则的缺点，又保持了封装对象创建过程的优点。

缺点：由于每加一个产品，句需要加一个产品工厂的类，增加了额外的开发量。

5、原型模式（Prototype）：原型实例制定创建对象的种类，并且通过拷贝这些原型创新的对象。关键是抽象类中有一个Clone的方法。（简历复印的例子）

优点：隐藏了对象创建的细节，对性能有很大的提高。不用重新初始化对象，而是动态地获得对象运行时的状态。

6、模板方法模式（TemplateMethod）：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可以重定义改算法的某些特定步骤。（考试题的例子）

优点：提供了一个很好的代码复用平台。

7、外观模式：（Facade）：为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个借口使得这一子系统更加容易使用。（炒股亏钱的例子）

优点：可以为复杂的子系统提供一个简单的接口，使得耦合大大降低，而且可以减少类之间的依赖，可以提供设计粗糙或高度复杂的遗留代码的比较清晰姜丹的接口，使新系统与Façade对象交互。

8、建造者模式（Builder）：将一个复杂对象的构件与他的表示分离，使得同样的构件过程可以创建不同的表示。（吃炒面没有放盐的例子）

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

9、观察者模式（Publish/Subscribe）：定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。（老板回来了，我不知道的例子）

优点：解除耦合、让耦合的双方的双方都依赖于抽象而不是依赖于具体，从而使得各自的变化都不会影响晾一边的变化。

10、抽象工厂模式（Abstract  Factory）：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。（换数据库的例子）

优点：易于交换产品系列，由于具体工厂类，在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。可以使具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户代码中。

11、状态模式（State）：当一个对象的内在状态改变时允许改变其行为，这个对象看起来像是改变了其类。（加班的例子）

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

12、适配器模式（Adapter）：将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。（姚明在NBA打球的例子）

优点：客户代码可以统一调用同一接口，这样更简单，更直接，更紧凑。

13、  备忘录模式（Memento）：在不破坏封装性的前提下，捕获一个对象的内部状态，并在改对象之外保存这个状态。这样以后就可将该对象回复到原先保存的状态。

优点：使用备忘录可以把复杂的对象内部信息对其他的对象屏蔽起来，从而可以恰当地保持封装的边界。在角色的状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原。

14、 组合模式（Composite）：将对象组合成树形结构以表示“部分—整体”的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。

优点：组合模式让客户可以一致的使用组合结构和单个对象。

15、 迭代器模式（Iterator）:提供一种方法顺序访问一个聚合对象中各个元素，而又不暴露改对象的内部表示。（想下车，先买票的例子）

优点：分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。

16、 单例模式（Singleton）：保证一个类仅有一个实例，并提供一个访问它的全局访问点。（有些类也需计划生育的例子）

17、桥接模式（Bridge）：将抽象部分与它的实现部分分离，使他们都可以独立的变化。（手机软件统一的例子）

优点：实现系统可能有多角度分类，每一种分类都有可能变化，那么就把这种多角度分离出来让它们独立变化，减少它们之间的耦合。

18、 命令模式（Command）：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化：对请求排队或记录请求日志，以及支持可撤销的操作。（烤羊肉串的例子）

优点：它能较容易的设计一个命令对列；在需要的情况下，可以较容易的将命令记入日志；允许接收请求的一方决定是否要否决请求；可以容易的实现对请求的撤销和重做；由于加进新的具体命令类不影响其他的类，因此增加新的具体命令类很容易；命令模式把请求一个操作的对象与指导怎么执行一个操作的对象分割开。

19、             职责链模式（Chain of Responsibility）:使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这个对象练成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。（加薪的例子）

优点：接收者和发送者都没有对方的明确信息，且链中的对象自己也并不知道链的结构。结果是职责链可简化对象的相互连接，它们仅需保持一个指向其后继者的引用，而不需保持它所有的候选接收者的引用。也就大大的降低了耦合度。

20、中介者模式（Mediator）:用一个中介对象来封装一系列的对象交互。中介者使对象不需要显式的相互引用，从而使其耦合松散，而且可以独立的改变它们之间的交互。（世界需要和平的例子）

优点：减少了各个抽象同事类的耦合，使得可以独立的改变和复用各个抽象同事类和中介者。把对象和协作进行了抽象，将中介作为一个独立的概念并将其封装在一个对象中，这样关注的对象就从对象各自本身的行为转移到它们之间的交互上来，也就是站在一个更宏观的角度去看待系统。

21、享元模式（Flyweight）：运用共享技术有效的支持大量细粒度的对象。（项目多也别傻做的例子）

优点:可以避免大量非常相类似的开销。

22、 解释器模式（interpreter）：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子。（其实你不懂老板的心的例子）

优点：很容易的改变和扩展文法，因为该模式使用类来表示文法规则。

23、 访问者模式（Visitor）：表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。（男人和女人的例子）

优点：把数据结构和作用于结构上的操作之间的耦合解脱开，使得操作集合可以相对自由的演化。将有关的行为集中到一个访问者对象中。

   原则：

1、  开放——封闭原则：是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。就是对于扩展是开放的，但对与修改是封闭的。

2、  单一职责原则：就一个类而言，应该仅有一个引起他变化的原因。

3、  依赖倒转原则：高层模块不应该依赖低层模块。两个都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象。

4、  迪米特法则：如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

5、  合成/聚合复用原则：尽量使用合成/聚合，尽量不要使用类继承。

     书中很常见的是开放——封闭原则和单一职责原则，据推测，这应该是每个模式必须要遵循的原则。

     做每件事之前都要有一个全局的认识，不能只是低头干活，不抬头看路……

     据说这本书要看好几遍，所以说设计模式很重要，我一定要好好学……争取开始学的时候是“小菜“，学完了不求能到”大鸟”的程度，只求“不菜“！