设计相关1-设计原则

1. 封装变化的部分
   找出那些容易或者可能会变化的部分，将他们与那些不变的部分分离开，这样我们日后维护的时候，影响会小些。

2. 针对接口编程，而不是针对实现编程
   所谓的针对接口编程，就是将变化的某种行为提取成一个接口，由多个实现类来实现不同的具体行为。使用时将接口给使用对象即可，而不是将具体的某种实现给使用对象。

3. 多用组合，少用继承
   使用组合可以很好的实现功能的动态绑定。使用继承的话，属于编译时绑定，有点太死板了，不能很好的适应一些变化。

4. 不写重复的代码
   重复的代码太多，浪费时间不说，维护成本也会正比增长。

5. 开闭原则
   对扩展开放，对修改关闭；通俗一点说就是：允许你在不修改原有逻辑的基础上进行扩展，禁止你通过修改原有逻辑进行功能的扩展；

6. 单一职责原则
   单一职责就是说，一个类或者一个方法，他们的功能尽可能的单一，也就是最好只干一种活。更深层一点的说，引起他们变化的维度（原因）应该是单一的。

7. 依赖倒置
   定义： 高层次的模块不应该依赖于低层次的模块，它们都应该依赖于抽象。抽象（接口、抽象类）不应该依赖实现（实现类），实现应该依赖抽象。
   依赖：A依赖B，即A使用B，比如B作为A的某个方法的参数、返回值；
   依赖倒置的核心思想其实就是面向接口编程。实现依赖倒置的常用方法：
   构造函数注入、setter注入、接口注入。

8. 里氏代换原则
   子类实例可以完美的代替父类实例而不影响程序原有功能的正确性。
   里氏替换的核心思想：类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。如果子类对父类方法任意修改，就会对整个继承体系造成破坏。

9. 接口隔离
   一个类对另外一个类的依赖是建立在最小的接口上。一个接口的功能应该是单一的。如果一个接口的功能太多，那么这个接口是不稳定的，会因为某个功能的变动而引发这个大接口的改动，显然增加了维护成本。

10. 迪米特法则
    迪米特法则又叫“最少知道原则”。一个类应该对自己调用的类知道得最少，我只和朋友类交流。

    朋友类的定义是这样的：出现在成员变量、方法的输入参数、方法的输出参数中的类称为成员朋友类，而出现在这个类的某个方法体内部的类不属于朋友类。

    方法是类的一个行为，在类的某个方法里使用另外一个类作为方法的局部变量，类竟然不知道自己的行为与其他类产生了依赖关系，这是不允许的。类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类除外。

    朋友间也是有距离的。迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private。一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。