设计模式原则
很多人在写代码的初始阶段懂了所写语言的语法后，经过不断地实践积累，总会发现自己代码的一些不足，要是是一个不断追求完美的人，就会不断地重构自己写过的代码，以达到各种优化程序，提升开发效率的目的。而随着不断的重构最终会发现重构的成本越来越重，可能到最后都不想做重构的工作了。所以对于大项目来说，为了以后项目的迭代，最应该注意的是从一开始就使用各种设计模式，避免各种高耦合导致的开发困难。
面向对象的开发模式有几个原则需要遵循：
- 开闭原则（Open Closed Principle，OCP）
- 单一职责原则（Single Responsibility Principle，SRP）
- 里氏代换原则（Liskov Substitution Principle，LSP）
- 依赖倒转原则（Dependency Inversion Principle，DIP）
- 接口隔离原则（Interface Segregation Principle，ISP）
- 合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）
- 最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则，Law Of Demeter）
开闭原则（Open Closed Principle，OCP）
- 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
这一原则很简单也很难，简单在一个这个原则就是叫Coder写了类或者函数的一些功能了，就不要改了，如果有需求的话，就对这些进行扩展，即可加不可改。而同样很难，难在要写出这样面相对象的代码时，每时每刻都要很清楚所写的代码已经足够抽象，使模块能被扩展而又不会影响其它模块，那么这样的代码写出来后就能在以后的迭代中更少地考虑是否会对现在的各种功能产生bug。
单一职责原则（Single Responsibility Principle，SRP）##
- 一个类只负责一项职责，不能存在多个导致类变更的原因。
这一原则很好理解，就是说类的性质在定义之前就要想好，类该负责一件事，而不是几件事，原因是假如负责了多件事，那么在代码量变大之后需要改一件事，由于耦合的原因，可能会导致其它负责的事情也受了影响，所以在定义的时候需要思考分析这个类具体的功能是否已经足够“原子”。
里氏代换原则（Liskov Substitution Principle，LSP）##
- 如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。
- 所有引用基类的地方必须能透明地使用其子类的对象。
这一原则描述的是父类与子类的关系，用开闭原则的角度来看就是“子类可以扩展父类，但是不能修改父类”。而在继承之后，要比较小心的是面向对象语言中重写与重载的使用。而对于“所有使用基类的地方必须能透明地使用其子类的对象”这个定义本身比较好理解，但是需要记住一些特殊的例子，即“企鹅是鸟不会飞”、“正方形是长宽相等的矩形”等等，更加深入地看，要注意以下几点：
- 子类重载父类方法时，子类方法的形参要比父类方法的形参需求要更少。
- 子类实现父类的抽象方法时，子类方法的返回值要比父类方法的返回值需求要更多。
依赖倒转原则（Dependency Inversion Principle，DIP）##
- 高层模块不应该依赖底层模块，二者都应该依赖其抽象；
- 抽象不应该依赖细节，细节应该依赖抽象。
这一原则目的是为了明确代码分层，高层模块是拥有复杂逻辑的代码模块，而底层模块为原子操作。当高层模块因为需求而修改依赖时，应该依赖的应为抽象，例如借口或协议，而不是直接依赖一个类。那么在这种情况下，只要原子操作的底层模块也实现了相关的接口或者协议，高层模块通过接口与底层模块进行联系，就可以使代码改变依赖产生的影响降低，这也是面向接口编程或面向协议编程的的基础。
另外，依照依赖倒转原则出了使用接口或者协议外，还有构造方法和setter方法两种方式。
所以当写底层模块的时候尽量要有抽象类或接口或协议，甚至都有，而变量的声明（尤其形参）类型尽量是接口或协议，那么在调用的时候，或许一开始并不清楚高层模块需要调用的底层模块是谁，所以这时遵循里氏替换原则调用就可以了。
接口隔离原则（Interface Segregation Principle，ISP）##
- 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
这一原则目的是让Coder在编程时，应该根据实际类的情况定义最小接口。当遵循依赖倒转原则后，就开始需要注意接口或协议了，在这里他们的存在最好是根据其使用的类而存在，假如把所以需要的接口方法都放到一个接口里，那么在一些类需要到一些接口的同时，也要实现很多可能会感觉到莫名其妙的接口，这不仅让接口代码变得臃肿，还会使代码变得难以理解和查阅。
遵循这个原则需要保持的事“细而专”，但是过犹不及，为一个接口方法就定义一个新接口，那是没有意义的，甚至还因为接口数量大了，在实现类里会变得很复杂。另外，因为最终目的是为了高类聚，低耦合，所以接口本身也是以最小为目的的，用最小的资源实现目的，需要Coder在设计的时候好好地斟酌。
合成/聚合复用原则（Composite/Aggregate Reuse Principle，CARP）##
- 合成表示严格的部分和整体关系，而部分和整体的生命周期一致。A拥有B，而B没有了A就没有了存在意义。
- 聚合表示宽松的包含关系，A可以包含B，但B没了A也可存在。
这一原则是用来减少继承的产生的，继承是一种高耦合的存在，只要父类有改变，那么子类也会有改变，而在一些情况下，继承关系和类的性质都已经定好了，在这时无法改变父类继承子类的实现，在这时候合成／聚合原则的选择能提供很好的解决方案。一个例子是人群、人、四肢，人群聚合（包含）了人，而人可以独立存在，四肢是人的部分，四肢脱离了人是存在不了的。
最小知识原则（Principle of Least Knowledge，PLK，也叫迪米特法则，Law Of Demeter）##
- 一个对象对其它对象应该保持最少的理解。（只与直接的朋友通信）
这一原则就是让代码低耦合，直接的朋友是指成员变量、方法参数、方法返回值，而局部变量中的却不是。这一原则跟单一职责原则很容易混淆，其区别是最小知识原则重点在于对沟通对象的选取来减少耦合，而单一职责原则则是防止错误的內聚导致以后代码的修改使功能出现问题。
##高內聚，低耦合##
在面向对象编程中，总原则“高內聚，低耦合”是共识，这里写的原则，是希望在总原则的情况下使用，就像合成／聚合复用原则，未必适合所有的情况，所以原则还是需要灵活地运用而不是生搬硬套。之后更会详细介绍基于这些原则的一些设计模式，同样道理，写代码的人是Coder，代码的意志由自己定义，灵活运用才是王道。