设计模式——设计原则

单一职责原则（SRP）

就一个类而言，应该仅有一个引起它变化的原因。

1. 手机功能众多但专一性并不很强。（拍摄，游戏，邮件）
2. 俄罗斯方块：下落，旋转，碰撞判断，移动，堆积，这些逻辑始终没变。可以移植pc，手机不同的平台。业务，界面，数据分离。如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会消弱或者抑制这个类完成其它职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会遭到意想不到的破坏。俄罗斯方块可移动的区域二维数组a[10][20], 若一个方块原来在【3】【5】下移就是【3】【6】，方块移动其实就是数组下标的变化，若【3】【6】的数组的值为1则表示有碰撞，不能移动。堆积就是判断【x】【y+1】是否是1，是就说明堆积将【x】【y】的值变为1.消层就是x从0~9是否都等于1，使得话就将此行数据清0，将其上方的数组值遍历，下移一位。
   软件设计真正要做的内容，就是发现职责，并把那些职责相互分离。判断是否应该分离出类来，就是如果你能想到多于一个的动机去改变一个类，那么这个类就具有多余一个的职责。
3. 编程时，要在类的职责分离上多思考，做到单一职责原则，这样代码才易维护，易扩展，易复用，灵活多样。

开放—封闭原则

软件实体（类，模块，函数等等）应该可以扩展，但是不可修改。
两个特性：对于扩展是开放的；对于更改是封闭的。
需求是一定会变化的，开放封闭可以实现。比如公司上班时间，弹性上班时间，目的是满足8小时工作制。（甚至时间不重要，业绩才是最重要的）
1.一国两制。社会主义制度不能修改，但允许增加一种制度。
2.何时应对需求变化：尽量在设计时，考虑种种需求的变化，将问题想周全了。即类设计及周全，写好就不用修改，需求变动，只是新增类而已，原代码能不动就不动。
3.无论模块多么封闭，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对它设计的模块应该对哪种变化封闭做出选择，它必须先猜测出最有可能发生变化的类，然后构造抽象来隔离那些变化。
在发生小变化时，就及早想方法应对发生更大变化的可能。等到变化发生时，立即采取行动。即不要在同一个地方摔倒两次
4.在最初编写代码时，假设变化不会发生。当变化发生时，就创建抽象来隔离以后发生的同类变化。如第一章刚开始的时候，加法，新增开方等。
5.面对需求，对程序的改动是通过增加新的代码进行的，而不是更改现有的代码。这就是开放封闭原则的精神所在。

我们希望的是在开发工作刚开始不久就知道可能发生的变化。查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。
6.开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象，然而，对于应用程序中每个部分都刻意的进行抽象也不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。
7.考研工作两不误。

依赖倒转原则

1.pc电脑最大的软件系统，任何部件如CPU,内存，硬盘，显卡都可以理解为程序中封装的类或程序集，由于pc易插拔的方式，不管哪一个出了问题，都可以在不影响其它的前提下，进行插拔更换。（强内聚，松耦合）
2.单一职责，内存坏了，不应该更换CPU。开放封闭，内存不够，可以增加内存条（只要插槽够）。
3.依赖倒转原则：抽象不应该依赖细节，细节应该更依赖抽象。针对接口编程，不要对实现编程。主板，内存，CPU都是针对接口设计的。

A.高层模块不应该依赖底层模块。两个都应该依赖抽象。
B.抽象不应该依赖细节。细节应该依赖抽象。
面向过程开发，常常将常用的代码写成函数封装成库，然后去调用。之后新项目也调用。比如访问数据库的封装成库，高层调用。若用户希望用不同的数据库，高层已经与底层耦合在一起了，高层的也不能复用。类似于若内存，CPU都依赖主板，主板一坏，所有的都不能用了。因此，只要接口是稳定的，那么任何一个更改都不会担心影响其它的。

里氏代换原则

一个软件的实体如果使用的是一个父类的话，那么一定使用于其子类，而且察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有任何变化。即子类型必须能够替换掉它们的父类型。
5.企鹅是一种鸟，但在编程世界，企鹅不能以父类，鸟的身份出现，因为鸟会飞，它不会。
6.只有当子类可以替换父类，软件单位的功能不受影响，父类才能真正地被复用，而子类也能够在父类的基础上增加新的行为。

由于子类型的可替换性，才使得父类类型的模块在无需修改的情况下就可以扩展。

UML类图

7. 依赖倒转即除了约定的接口，谁也不需要依赖谁，大家都可以灵活自如。依赖倒转是面向对象设计的标志，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之就是过程化设计。

迪米特法则

背景：入职手续，让找生产部小李领电脑，但小李不在，其他人不管。若让找生产部得领导，则由他安排人，会好很多。
又叫最少知识原则。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某个方法，可以通过第三者转发这个调用。
1.该法则首先强调的前提是在类的结构设计上，每一类都应当尽量降低成员的访问权限。即类的私有不要暴露在外面。
2.根本思想是强调了类之间的松耦合。类之间的耦合越弱，越有利用复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。信息的隐藏促进了软件的复用。（小李离职的话，可以有他们部门的领导重新指派人）

合成聚合复用原则

优先使用合成聚合复用原则，而不是类继承。

好处：优先使用对象的合成/聚合将有助于保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小的规模，并且不太可能增长为不可控制的庞然大物。