设计模式----原则

开闭原则

对扩展开放，对修改关闭。当需求发生变化时，我们可以通过添加新模块来满足新需求，而不是通过修改原来的实现代码来满足新需求；开放封闭原则是面向对象设计的核心所在，遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现的频繁变化的那些部分作出抽象，然而，对于应用程序中的每个部分都刻意的进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

1. 通过接口或者抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法。
2. 参数类型、引用对象尽量使用接口或者抽象类，而不是实现类
3. 抽象层尽量保持稳定，一旦确定不允许修改

单一职责

控制类的粒度大小，将对象解耦、提高其内聚性。一个类或者一个接口只负责唯一项职责，尽量设计出功能单一的接口。当我们在编程的时候，很自然的会一个类加上各种各样的功能。这样意味着，无论任何需求要来，你都需要更改这个类，这样其实是很糟糕的，维护麻烦，复用不可能，也缺乏灵活性。如果一个类承担的职责过多，就等于把这些职责耦合起来，一个职责变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭到很多意想不到的破坏。

里氏替换原则

确保父类所拥有的性质在子类依赖成立。里氏代换原则是面向对象设计的基本原则之一。即任何基类可以出现的地方，子类一定可以出现。里氏代换原则是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受影响时，基类才能被真正复用，而衍生类也能够在积累的基础上增加新的行为，里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。在基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。当满足继承的时候，父类肯定存在非私有的成员，子类肯定是得到了父类的这些非私有成员（假设，父类的成员全部是私有的，那么子类没办法从父类继承任何成员，也就不存在继承的额概念了）。既然子类继承了父类的这些非私有成员，那么父类对象也就可以在子类对象中调用这些非私有成员。所以，子类对象可以替换父类对象的位置。
在里氏带环原则下，当需求有变化时，只需继承，而别的东西不会改变。由于里氏代换原则才使得开放封闭称为可能。这样使得子类在父类无需修改就可以扩展。

依赖倒置原则

面向接口编程，不要面向实现编程。高层模块不应该依赖低层模块具体实现，解耦高层与低层。既面向接口编程，当实现发生变化 时，只需提供新的实现类，不需要修改高层模块代码。
高层模块不应该依赖于低层模块(变化)，二者都应该依赖于抽象(稳定)
抽象(稳定)不应该依赖于实现细节(变化)，实现细节应该依赖于抽象(稳定)

接口隔离原则

要为各个类建立它们需要的专用接口。每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。接口应该小而完备。换句话说，客户端不应该依赖他不需要的接口，类间的依赖关系应建立在最小的接口上。但是“小”是有限度的，不能违反单一职责原则。

最少知道原则(迪米特法则)

只与直接朋友交谈，不要和“陌生人”交谈；直接朋友包括：

1. 以参数形式传入到当前对象方法中的对象
2. 当前对象的成员对象
3. 如果当前对象的成员对象是一个集合，那么集合中的元素也都是朋友
4. 当前对象创建的对象
5. 当前对象本身（this）

一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。

合成复用原则

尽量先使用组合或聚合等关联关系，其次才考虑使用继承关系来实现。合成/聚合复用原则经常又叫做合成复用原则，就是在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分，新的对象通过这些对象的委派达到复用已有功能的目的。

总结

1. 优先使用对象组合，而不是类继承。类继承通常为“白箱复用”，对象组合通常为“黑箱复用”，继承在某种程度上破化了封装性，子类父类的耦合性过高。
2. 封装变化点；使用封装来创建对象之间的分界层，让设计者可以在分界层一侧进行修改，而不会对另一侧产生不良的影响，从而实现松耦合。
3. 针对接口编程，而不是针对实现编程。不将变量类型声明为某个特定的具体类，而是声明为某个接口客户程序无需获知对象具体类型，只需要知道对象所具有的接口减少系统中各部分的依赖关系，从而实现“高内聚，低耦合”的类型设计方案。