经典伴读_GOF设计模式_始终如一

经典伴读系列文章，不是读书笔记，自己的理解加上实际项目中运用，旨在5天读懂这本书。如果这篇文章对您有些用处，请点赞告诉我O(∩_∩)O。

• 如何使用设计模式抽象实例化过程。请参考《经典伴读_GOF设计模式_创建型模式》
• 如何组合类和对象以获得更大的结构。请参考《经典伴读_GOF设计模式_结构型模式》
• 对象或类之间的通信模式，请参考《经典伴读_GOF设计模式_行为模式（上）》，《经典伴读_GOF设计模式_行为模式（下）》

设计模式一览

好了，终于到了这一刻，经过4篇文章的学习，23种设计模式都已经学了一遍，想检测自己学懂了没，最简单的方式就是看下面这些模式定义，当初迷迷糊糊不知所云的概念，现在读起来是否觉得，GOF描述的很准确呢，至少我已经恍然大悟。（如果仍然有疑惑，请参考前面的文章）

创建型模式（5）

抽象对象实例化过程：

• AbstractFactory：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
• FactoryMethod：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。 Factory Method使一个类的实例化延迟到其子类。
• Singleton：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
• Prototype： 用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象。
• Builder：将 一 个复杂对象的构建与它的表示分离 ，使得同样的构建过程可以创建不同的表示。

结构型模式（7）

组合类和对象以获得更大的结构：

• Adapter：将一个类的接口转换成客户希望的另外一个接口。 Adapter模式使得原本 由于接口不兼容而不能一起工作的那些类可以一起工作。
• Bridge：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
• Composite：将对象组合成树形结构以表示 “部分-整体 ” 的层次结构。Composite使得客户对单个对象和复合对象的使用具有一致性。
• Decorator：动态地给一个对象添加一些额外的职责。就扩展功能而言， Decorator模式比生成子类方式更为灵活。
• Facade：为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。
• Flyweight：运用共享技术有效地支持大量细粒度的对象。
• Proxy：为其他对象提供一个代理以控制对这个对象的访问。

行为模式（11）

对象或类之间的通信模式：

• Chain Of Responsibility：为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它。
• Command：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数 化;对请求排队或记录请求日志，以及支持可取消的操作。
• Interpreter：给定一个语言 , 定义它的文法的一种表示，并定义一个解释器 , 该解释器使用该表示来解释语言中的句子。
• Iterator：提供一种方法顺序访问一个聚合对象中各个元素 , 而又不需暴露该对象的内部表示。
• Mediator： 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。
• Memento：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态。
• Observer：定义对象间的一种一对多的依赖关系 , 以便当一个对象的状态发生改变时 , 所有依赖于它的对象都得到通知并自动刷新。
• State：允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。
• Strategy：定义一系列的算法, 把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户。
• Template Method：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
• Visitor：表示一个作用于某对象结构中的各元素的操作。 它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。

模式关键词

就算理解了模式定义，也不可能全部一字不落的背下来，如何能够快速判断当前业务场景，适用于哪种模式。我们需要记住的是模式关键字。

设计原则

GOF设计模式书中并没有提到设计原则，然而学完设计模式后再来看这六大原则，是不是又豁然开朗了。

• 单一职责原则：只能有一个原因导致类的变更。
  如：用户登录和用户管理，虽然都有用户，但职责不同，需要分离。

• 开闭原则；对外扩展开放，对内修改关闭。
  设计模式大多都符合，如状态模式（增加状态），策略模式（增加策略）等。

• 里氏替换原则；子类对象可以替换父类对象。
  这里指的是不能重写父类的方法，如已经使用了父类的系统，在使用子类向上转型后，不影响系统原有功能。这里和多态并不冲突，多态强调的是多个子类实现接口，接口或父类没有完整的功能。

• 迪米特法则；一个对象应该对其他对象有最少的了解。
  又叫“最少知道法则”，如会开车，不需要知道车内部是如何运作的，外观模式就是典型代表。

• 接口隔离原则；客户端不应该依赖它不需要的接口。依赖应该建立在最小的接口上。
  如我只用查询方法，就不要给我一个增删改查的接口。万一我使用了修改的方法，你又重构了这个方法，你又不知道我用了…这就是一个线上事故了。接口隔离原则和迪米特法看着相似，其实侧重点不同，前者是为了减少依赖，撇清责任，后者则是为了提供更便捷的复合接口。

• 依赖倒置原则：依赖抽象而不是依赖实现。
  即面向接口编程，而不是面向实现编程。多态，Spring依赖注入中都有体现，然而事事无绝对，对于通用的框架代码肯定是面向接口的，但对于具体定制的业务代码却不一定。如Dao的接口，对于大多不切换数据层的项目来说，意义何在？

完！