【手写源码-设计模式】-总论-基于GOF23种设计模式模拟不同场景解析

1、设计模式概念

        设计模式（Design pattern） 是解决软件开发某些特定问题而提出的一些解决方案也可以理解成解决问题的一些思路。通过设计模式可以帮助我们增强代码的可重用性、可扩充性、 可维护性、灵活性好。我们使用设计模式最终的目的是实现代码的高内聚和低耦合。        

        GOF是设计模式的经典名著Design Patterns: Elements of Reusable Object-Oriented Software（中译本名为《设计模式——可复用面向对象软件的基础》）的四位作者，他们分为是：Elich Gamma、Richard Helm、Ralph Johnson、以及John Vlissides。这四个人常被称为Gang of Four， 即四人组，简称GOF。

2：学习设计模式的疑惑

1：设计模式是否有必要全部学一遍？

        Yes！别被那些说什么设计模式大多用不上，根本不用全薛的舆论所左右。尽管现在设计模式远远不止23种，对所有都有研究是太不容易的，但就像本人一样，在学习GOF总结的23个设计模式的过程中，你会被那些编程大师们进项伟大的技术思想洗礼，不断增加自己对面向对象的深入理解，从而更好的把这种思想发言光大。这就如同高中时学立体几何感觉没用，但当你装修好房子购买家具时才知道，有空间感，懂得空间计算如何的重要，你完全可能遇到买了一个大号的冰箱缺放不进厨房，或买了开关门的衣柜缺因床在旁边堵住了门而打不开的尴尬。
        重要的不是你将来会不会用到这些模式，而是通过这些模式会让你找到“封装变化”，“对象间松耦合”，“针对接口编程”的感觉，从而设计出易维护，易扩展，易复用，灵活性好的程序。成为诗人后可能不需要刻意地按照某种模式去创作，但成为诗人前他们一定是认真的研究过成百上千的唐诗宋词，古今名句。
        如果说，数学是思维的体操，那设计模式，就是面向对象编程思想的体操。

2：设计模式有四个境界

第一层：没学前是一点不懂，根本想不到用设计模式，设计的代码很糟糕。
第二层：学了几个模式后，很开心，于是到处想着要用自己学过的模式，于是时常造成误用模式而不自知。
第三层：学完全部模式，感觉诸多模式极其相似，无法分清模式之间的差异，有困惑，但深知误用之害，应用之时有所犹豫。
第四层：灵活应用模式，甚至不应用具体的某种模式也能设计出非常优秀的代码，以达到无招胜有招的境界。

3：不要怂，冲冲冲

        不会用设计模式的人要远远超过过渡使用设计模式的人，从这个角度讲，因为怕过渡设计而不用设计模式显然是因噎废食。

        当你认识到自己有过度使用模式的时候，那就证明你已意识到问题的存在，只有通过不断的钻研和努力，你才能突破“不识庐山真面目，只缘身在此山中”的瓶颈，达到“会当凌绝顶，一览众山小”的境界。

3、设计模式的三大分类

 1、创建型模式

对象实例化的模式，创建型模式用于解耦对象的实例化过程。

单例模式：某个只能有一个实例，提供一个全局的访问点。

工厂方法模式：一个工厂类根据传入的参量决定创建出哪一种产品类的实例。

抽象工厂模式：创建相关或依赖对象的家族，而无需明确指定具体类。

建造者模式：封装一个复杂对象的创建过程，并可以按步骤构造。

原型模式：通过复制现有的实例来创建新的实例。

简单工厂模式：由一个工厂对象决定创建出哪一种产品类的实例。

2、结构型模式

把类或对象结合在一起形成一个更大的结构。

适配器模式：将一个类的方法接口转换成客户希望的另一个接口。

桥接模式：将抽象部分和它的实现部分分离，使它们都可以独立的变化。

组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构。

装饰器模式：动态的给对象添加新的功能。

外观模式：对外提供一个统一的方法，来访问子系统中的一群接口。

代理模式：为其它对象提供一个代理以便控制这个对象的访问。

享元模式：通过共享技术来有效的支持大量细粒度的对象。

3、行为型模式

类和对象如何交互，及划分责任和算法。

解释器模式：给定一个语言，定义它的文法的一种表示，并定义一个解释器。

模板方法模式：定义一个算法结构，而将一些步骤延迟到子类实现。

责任链模式：将请求的发送者和接收者解耦，使的多个对象都有处理这个请求的机会。

命令模式：将命令请求封装为一个对象，使得可以用不同的请求来进行参数化。

迭代器模式：一种遍历访问聚合对象中各个元素的方法，不暴露该对象的内部结构。

中介者模式：用一个中介对象来封装一系列的对象交互。

备忘录模式：在不破坏封装的前提下，保持对象的内部状态。

观察者模式：对象间的一对多的依赖关系。

状态模式：允许一个对象在其对象内部状态改变时改变它的行为。

策略模式：定义一系列算法，把他们封装起来，并且使它们可以相互替换。

访问者模式：不改变数据结构的前提下，增加作用于一组对象元素的新功能。

4、设计模式的原则

1、单一职责原则

对于一个类，只有一个引起该类变化的原因；该类的职责是唯一的，且这个职责是唯一引起其他类变化的原因。

2、接口隔离原则

客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。

3、依赖倒转原则

依赖倒转原则是程序要依赖于抽象接口，不要依赖于具体实现。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

4、里式代换原则

任何基类可以出现的地方，子类一定可以出现。里氏代换原则是继承复用的基石，只有当衍生类可以替换基类，软件单位的功能不受影响时，基类才能真正的被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

5、开闭原则

（1）对于扩展是开放的（Open for extension）。这意味着模块的行为是可以扩展的。当应用的需求改变时，我们可以对模块进行扩展，使其具有满足那些改变的新行为。也就是说，我们可以改变模块的功能。

（2）对于修改是关闭的（Closed for modification）。对模块行为进行扩展时，不必改动模块的源代码或者二进制代码。模块的二进制可执行版本，无论是可链接的库、DLL或者.EXE文件，都无需改动。

6、迪米特法则

迪米特法则又叫做最少知识原则，就是说一个对象应当对其它对象又尽可能少的了解，不和陌生人说话。

7、合成复用原则

合成复用原则要求在软件复用时，要尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。如果要使用继承关系，则必须严格遵循里氏替换原则。合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。