前言
我认为可以将设计由低到高分为以下3个层次：
- 设计原语
- 设计模式
- 架构模式
层次1更多关注具体语言上的技巧，本系列文章讨论的是层次2.
作为开头第一篇，希望读者不要抱着”套用”的想法学习设计模式。GOF这本书列举了常用的23种设计模式，去背诵下来，在开发时考虑特征符合哪种设计模式，然后去套用，并不是学习设计模式的目的，设计模式需要关注的是设计而非模式。
GOF这本书的重点就在前几章，通过一个编辑器的例子去告诉你思考的方向。我个人观点，设计模式的重点就在本文提到的几大原则的理解。这几大原则记不住也没关系，可以概括成一句话，寻找稳定和变化的界限，封装稳定，扩展变化，即封装变化点。相信只要学会思考哪一部分是稳定的，哪一部分是变化的，代码能够做到隔离稳定和变化，变化依赖稳定，那么即使它不属于现有设计模式的任何一种，它也是设计模式。
本系列文章全部用C++作为例子。关于C++，我补充几种重构技法:
- 静态->动态
- 早绑定->晚绑定
- 继承->组合
- 编译时依赖->运行时依赖
- 紧耦合->松耦合
S.O.L.I.D
常见的有如下5个：
SRP 单一责任原则
The Single Responsibility Principle
不存在多于一个的因素导致类的状态发生变更。变化方向隐含类的责任
OCP 开闭原则
The Open Closed Principle
对扩展开放，对修改关闭
LSP 里氏代换原则
The Liskov Subsitution Principle
子类能替换父类。继承表达类型抽象
ISP 接口隔离原则
The Interface Segregation Principle
不应该强迫客户程序依赖他们不用的方法。接口应该小而完备。
DIP 依赖倒置原则
The Dependency Inversion Principle
高层次模块(稳定)不应该依赖于低层次模块(变化)，二者都应该依赖于抽象(稳定)。抽象(稳定)不依赖于实现细节(变化)，实现细节应该依赖于抽象(稳定)
L.C.C.S.S
LOD 迪米特法则
The Law of Demeter
有被称为最少知识原则。一个对象对其他对象应该有最少的了解。
CRP 合成复用原则
The Composite Resuse Principle
优先使用对象组合，而不是类继承。类继承通常是白箱复用，对象组合通常为黑箱复用。继承在某种程度上破坏了封装性，子类父类耦合度高。
CCP 共同封闭原则
The Common Closure Principle
一起修改的类，应该组合在一起。如果必须修改应用程序代码，我们希望所有修改都发生在一个包里，而不是遍布在很多包里
SAP 稳定抽象原则
The Stable Abstractions Principle
最稳定的包应该是最抽象的包
SDP 稳定依赖原则
The Stable Dependencies Principle
包之间的依赖关系应该是稳定方向依赖的，包要依赖的包要比自己更具有稳定性