大话设计模式（一）

楼主，一直以来很仰慕大神们的犀利代码功底，像SIKI老师一直是我敬仰的大神。自己苦于没有技术能力，一天在群里看到发的《大话设计模式》，雄心冲冲，想想终于可以修炼一番。然而，现实的状态像是一只爬行的蜗牛，经过很长很长的一段时间才看完，也算小有收获。写这篇简文，一是为了记录自己的学习笔记；二是为了满足自己小小的虚荣。也算明心敬志了。

在写设计模式之前先说一下设计模式的六大原则：（摘抄自书中）

1.单一职责原则。对一个类而言，应该仅有一个引起他变化的原因。一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。在软件设计中，应避免过多的职责耦合，应该发现职责并将那些职责相互分离。

2.开放封闭原则。是说软件实体（类、模块、函数等等）应该可以扩展，但是不能修改。简单的说就是对扩展开放，对修改关闭。面对需求，对程序的改动是通过增加新代码实现的，而不是更改现有的代码。无论一个模块多么的“封闭”，总有一些无法封闭的变化，在程序设计时应提前猜测最有可能的变化种类，并用构造抽象进行隔离，但要拒绝刻意的、不成熟的抽象。开放封闭原则是面向对象的核心，遵循这个原则可以带来可维护、可扩展、可复用、灵活性好等巨大好处。

3.依赖倒置原则。高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。程序要依赖于抽象接口，不要依赖于具体实现。也是就说要针对接口（抽象）编程，不要对实现编程。这样就降低了客户与实现模块间的耦合。依赖倒置是面向对象的标志，使用哪种语言来编程不重要，应考虑如何针对抽象编程，不要针对细节编程。面向对象的设计，程序中所有的依赖关系应终止于抽象类或接口。

4.里氏代换原则。子类型必须能够替换他们的父类型。一个软件实体如果使用的是一个父类，那么一定适用其子类，而且觉察不出父类对象和子类对象的区别。也就是说在软件里，把父类都替换成它的子类，程序的行为没有变化。这个原则使得继承复用成为可能。只有子类可以替换父类，软件单位的功能不受影响时，父类才被真正的复用，而子类也可以在父类的基础上增加新的行为。子类类型的可替换性使得父类类型的模块在无需修改的情况下就可以扩展，（扩展开放修改关闭）这也是符合开放封闭原则。

5.接口隔离原则。客户端不应该依赖它不需要的接口；一个类与另一个类的依赖应建立在最小的接口上。应避免庞大的接口，尽量细化成小的接口，但有限度。接口隔离原则注重接口依赖的隔离，约束接口，针对抽象，是对程序整体架构的构建。单一职责原则主要约束类，其次是接口和方法，是针对程序的实现和细节。

6.迪米特法则。如果两个类不必彼此直接通信，那么这两个类就不应该发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法，可以通过第三者转发这个调用。在类的结构设计上，每一个类都应当尽量降低成员的访问权限。迪米特法则的根本思想是强调类之间的松耦合。类之间的耦合度越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类发生波及，信息的隐藏促进了软件的复用。

7.合成复用原则。尽量使用对象组合，而不是继承达到复用的目的。 面向对象的设计，若两种方法都可以实现在不同环境中的复用，应优先考虑使用组合/聚合，其次才是继承。通过继承达到复用，继承会把父类的实现细节暴露给子类，破坏了系统的封装性。通过合成/聚合达到复用，新对象可以调用原有的对象的功能，而成员对象的内部实现细节对于新对象不可见，耦合度相对较低。设计模式的六大原则是不包括这一原则的。

设计模式默认有23种，总体分为三大类：创建型模式；结构型模式；行为型模式。（借鉴摘抄）

1.创建型模式：与对象创建有关。创建型模式对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。创建型模式隐藏了类的实例的创建细节，提供统一的接口（方法），使得系统的设计更符合单一职责原则。

创建型模式包括：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

2.结构型模式：处理类或对象的组合。结构型模式将类或者对 象通过继承关系或依据合成复用原则使用关联关系结合在一起形成复杂的、功能更为强大结构。

结构型模式包括：适配器模式、装饰模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

3.行为型模式：描述类或对象如何交互及如何分配职责。行为型结构不仅关注类和对象的关系，更注重它们之间的相互作用。行为型模式，可以更加清晰地划分类与对象的职责，并研究系统在运行时实例对象之间的交互。

行为型模式：观察者模式、模板方法模式、命令模式、状态模式、责任链模式、策略模式、备忘录模式、迭代器模式、访问者模式、中介者模式、解释器模式。

(未完待续)