设计模式六大原则

单一职责原则（拍摄UFO）——就一个类而言，应该仅有一个引起它变化的原因

如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。

软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。在编码时，我们要在类的职责分离上多思考，做到单一职责，这样才是真正的易维护、易扩展、易复用、灵活多样。不然的话，把各种代码，算法，SQL语句什么的都放到一个类里面，当欲求要改变时，就要更改这个类了，这样很糟糕，维护麻烦，复用不可能，也缺乏灵活性。单一职责原则告诉我们实现类要职责单一。

开放—封闭原则（考研求职两不误）：对软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。

面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。对程序中呈现出频繁变化的那些部分做出抽象。用抽象构建框架，用实现扩展细节。由于有了里氏代换原则，才使得开放封闭成为了可能。

正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。开放封闭原则告诉我们对扩展开放，对修改关闭。

依赖倒转原则（会修电脑不会修收音机？）——高层模块不应该依赖低层模块。两个都应该依赖抽象

抽象不应该依赖细节。细节应该依赖抽象。

依赖倒转原则是面向对象的标志，不管高层还是低层都依赖与抽象（接口或抽象类），只要接口稳定，那么任何一个的更改都不用担心其他收到影响，这就使得无论高层模块还是低层模块都可以很容易地被复用。

谁都不依靠谁，约定一个接口，就都灵活自如了。依赖倒转原则告诉我们要面向接口编程。

里氏代换原则——子类型必须能够替换掉他们的父类型

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它觉察不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序行为没有变化。因为子类拥有父类所有非private的行为和属性。

里氏代换原则使得继承复用成为了可能，只用当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。

子类对父类进行继承复用，在父类能实现的功能，子类都能实现，所以子类可以替换掉父类的位置，完成了继承体系。

迪米特法则，也叫最少知识原则（无熟人难办事？）——如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用

其根本思想是强调了类之间的松耦合。类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。就书上的例子来说，小菜第一天上班，不会认识IT部门的人呢，如果公司有很好的管理，那么应该是人事部的人打个电话到IT部，告诉主管安排人给小菜装电脑，就算开始是小张负责，他临时有事主管也会安排其他人来处理，而不至于小张很忙，小李很闲，却没人理小菜。迪米特法则告诉我们要降低耦合

合成/聚合复用原则——尽量使用合成/聚合，尽量不要使用类继承。

聚合表示一种弱的拥有关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分，如大雁和雁群

合成则是一种强的拥有关系，体现的是严格的部分与整体的关系，部分和整体的生命周期一样，如翅膀和大雁

好处：有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。就如书中的例子，手机品牌和手机软件，让不同的品牌和功能都分别继承于它们，这样要增加新的品牌或新的功能都不用影响其他类了，不会造成一个庞大繁杂的结构图。