设计中的六大原则

设计的六大原则：
（1）开闭原则
对于一切程序，都应该是对修改关闭，对扩展开放的。怎样才能做到开闭原则呢，关键是在于抽象，抽象的目的就在于找出不变点，封装变化点，那么这样就能实现开闭了。
但是这只是一种理想的情况，在任何时候，都不可能做到完全的符合开闭原则，因为开闭一定只能是某一个抽象角度的开闭，那么换一个抽象角度，那么当前选择的开闭的角度就有可能成为障碍。难道就只能靠预测抽象的角度么，不太靠谱。所以个人觉得只有在明显的看到变化点的时候，才会去进行这样的抽象，否则就会引起不必要的复杂性的臭味。
（2）依赖倒转原则
细节应该依赖于抽象，抽象不应该依赖于细节。
这话怎么说呢，只能说接口与其客户之间的依赖关系，远远强于接口与其实现者之间的依赖关系。
（3）李氏代换原则
表述：对于任意类A的对象o1,都存在任意类B的对象o2，在所有使用到o1的地方，都能够用o2代替，而不会对客户产生任何影响，那么就可以说B是A的子类。
怎样验证是否符合李氏代换原则？
子类与父类直接的关系，就是所谓的is-a的关系。但是这里的is-a是行为上的is-a的关系。
同样的父子关系，需要放到某一个上下文中去看，才能判断出这样的关系是否违背的李氏代换原则。
那么什么是不同的上下文呢，其实也就是说，类的不同的行为，某一些行为，可能会使这样的关系违背李氏代换原则。那么这个时候我们应该怎么办呢，可以有一个办法就是抽象出父子类的不违背李氏代原则的行为，组成一个新的超类，然后原来的两个类就由父子关系变成了兄弟关系。
还有一种方便判断是否符合李氏代换原则的方法，就是使用契约式编程。设定了前置条件与后置条件。那么子类覆盖的方法，那么就必须要有跟宽松的前置条件和更严格的后置条件，稍微思考一下就知道原因是什么。
对于可能有不符合李氏代换原则的一些代码现象。
有一个很明显的现象就是子类提供了一种退化了的方法。
（4）接口隔离法则
首先要说的一件事情就是接口跟谁的联系更紧密一些呢，是接口的使用者还是接口的实现者，很明显，是接口的使用者，他们之间的关联关系远远紧密与接口与其实现者之间的关系。那么这个时候，先有接口后有实现，那么情况就比较明显了，从客户使用的角度来说，接口天然是隔离的，没啥好说的的。
而多个接口，最终可能只有一个实现者，这是很正常的。
（5）单一职责原则
既然是单一职责原则，那么不得不弄清楚的就是，什么是职责，怎样才能划分出不同的职责。
其实就是不同的抽象角度，不同的抽象角度决定了不同组的职责，而每一个抽象角度决定了每一个变化的维度，那么多组职责糅合在一起的时候，会发生什么变化呢，就会使本来不需要受到影响的客户受到了无辜的影响，这个很致命。所以说，单一职责原则，还是需要遵循的。但是职责的划分，没有什么定例，个人决定全凭个人决定的抽象角度。
（6）迪米特法则
这个法则又称最小知识原则，举个例子，A依赖于B，B依赖于C，A依赖于C，那么这个时候就可以断开A与C的依赖关系，通过将行为委托给B，然后A只会依赖于B，这个时候就将A与C解耦了。如果遵循这个原则，那么最后的依赖关系图就成为了一个树状结构，相当的理想。