设计原则
1、单一职责原则（SRP）
就一个类而言，应该仅有一个引起它变化的方法的原因。
比如设计设计 俄罗斯方块 ，通过二维数组表示坐标，所谓游戏的逻辑，只不过是数组的每一项值的变化问题，下落、旋转、碰撞判断、移动、堆积都是在做数组具体项的值的变化。应将此程序分为两个类，一个是游戏的逻辑类，一个是WinForm窗体的类。即便当有一天需要改变界面，只不过是窗体类的变化，与游戏逻辑无关，以此达到复用的目的。
软件设计真正要做的内容，就是发现职责并把那些职责相互分离。如果你能够想到多于一个动机去改变一个类，那么这个类就具有多于一个职责，就应该考虑类的职能分离。
-----------------------------------------------------------------------
2、开放 - 封闭原则（OCP）
对于软件实体（类、模块、函数等等）应该可以扩展，但不可修改。对于扩展是开放的，对于更改是封闭的。
在做任何系统的时候，一开始不可能确定需求的，需求一定会发生变化。
在我们编写代码时，假设变化不会发生。当发生变化时，我们创建抽象来隔离以后发生的同类变化。例如：如果只是写一个加法程序，可能在client类完成，但是假设之后需要加多个减法运算，你会发现需要修改原来的类，那么就违背了“开放 - 封闭”原则。应该添加一个抽象的运算类，用继承多态的方式降低耦合度。
对于程序的改动，是通过增加新代码来进行，而不是更改现有的代码。应该仅对程序中频繁出现的那些部分作出抽象。
-----------------------------------------------------------------------
3、依赖倒转原则
高层模块不应该依赖低层模块，两个都应该依赖抽象。
抽象不应该依赖细节，细节应该依赖抽象。
针对接口编程，不要对实现编程。例如无论主板还是、CPU、内存、硬盘都是针对接口设计的，如果针对实现来设计，那么内存就要具体到某个品牌的主板了。
里氏代换 -- 一个软件实体如果使用的是一个父类的话，那么一定适用其子类，而它察觉不出父类对象与子类对象的区别。简单得说：子类型必须能够替换掉它们的父类型。
企鹅虽然是鸟类，但是不会飞，在编程中不能继承鸟类，因为子类拥有父类非private方法和属性。只有当子类可以替换父类，软件的功能不受影响时，父类才能真正被复用，而子类也能父类的基础上增加新的行为。
高层模块不应该依赖低层模块，比如业务逻辑依赖DB访问操作，两者都应该分别抽象出类，再通过抽象类在实现调用。
4、迪米特法则
如果两个类不必彼此直接通讯，那么着两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
迪米特法则首先强调的前提是在类的结构设计上，每一个类都应当尽量降低成员的访问权限。也就是说一个类包装好自己的private状态，不需要让别的类知道得字段或者行为就不要公开。
迪米特法则其根本思想：强调了类之间的松耦合性。
类之间耦合性越弱，越有利于复用，一个处于弱耦合的类被修改，不会对有关系的类造成波及。
例如：小菜第一天去公司，只认识人事部的小杨，小杨让小菜去找IT部的小张签拿电脑，但IT部中只有小李在，小张忙去了，小李很闲但是负责小菜的电脑不是他，所以小菜只能等半天，要等到小张回来才能办理。
应该让人事部小杨打电话给IT部门，让主管安排人给小菜负责电脑，就算一开始是小张负责，他有事临时出去，主管也可以安排小李负责。由于IT部门是抽象的，哪怕里面的人都换成新人，电脑出现问题也可以找IT部门解决，而不需要认识里面的同事。
5、合成/聚合复用原则
尽量使用合成/聚合，尽量不要使用类继承。
聚合是一种弱的“拥有”关系，体现的是A对象可以包含B对象，但B对象不是A对象的一部分。
合成是一种强的“拥有”关系，体现了严格的部分和整体的关系，部分和整体的生命周期一样。
优先使用对象的合成/聚合有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小的规模，并且不大可能增长为不可控制的庞然大物。
6、里氏代换原则
一个软件实体如果使用的是一个基类的话，那么一定适应于其子类，而且它根本不能察觉出基类对象和子类对象的区别。
例如：父类 Horse（马），白马 和 黑马 都是马的子类。如果有一操作（跑）适用于马，那么必然也适用于白马与黑马。
根据里氏代换原则，正方形不能是长方形的子类，假设长方形有一方法是长度变成宽的两倍，正方形是永远不可能实现，最终报错。
Java对里氏代换的支持：假设父类Base有一方法public method()，那么其子类不能将该方法的访问权限由public 改成 protect 或 private，否则报编译错误。
