设计模式六大原则
前言
看了设计模式的前五章，就遇到了四个原则，那么还有其他的原则吗？现在就一起来总结一下。
在大话设计模式这本书中我只看到了五个原则，当然了，我们要多方面学习，CSDN博客就是我们最好的巨人。在Csdn中查看了一下设计模式的原则，是有六大原则，分别有：单一职责原则，开放-封闭原则， 依赖倒转原则， 里氏代换原则， 迪米特法则， 接口隔离原则。下面分别来学习一下。
六大原则：
单一职责原则（SPR）
what：
这个由字面意思就很好理解了，顾名思义，功能要单一。
准确的解释是：就一个类而言，应该仅有一个引起它变化的原因。
why：
我们在做编程的时候，很自然给一个类加各种各样的功能，这就意味着，无论任何需求要来，都需要改这个窗体类，这样维护麻烦，不能复用，缺乏灵活性。
场景：
当你看见天空有一道彩虹，特别想拍下来留作纪念，但是由于手机像素不好，拍出来的照片都不是自己想要的效果，这时候就该懊恼了，为什么手机的相机功能不能强大一点呢？就像数码相机一样，它其实就是将功能单一化，精进化了，但是也不等于智能手机职责多，就不能做好，只不过现在的科技还不能让手机在摄像时超过DV（点我啊）而已，
how：
所以我们在编程时，要在类的职责分离上多思考，做到单一职责，这样你的代码才是真正的易维护，易扩展，易复用，灵活多样，
开放-封闭原则
what：
开放-封闭原则，对什么开放？对什么封闭呢？
这个原则其实是有两个特征，一个是说“对于扩展是开放的(open for extention)“，另一个是说”对于更改是封闭的(colsed for modification)”。
why：
设计软件要容易维护又不容易出问题的最好的办法，就是多扩展，少修改。
我们在做任何系统的时候，都不要指望一开始需求确定了，就永不再变，这是不科学也是不现实的想法。既然需求一定会变化，那么在设计软件时可以相对容易修改。不至于说，新需求一来，就推到整个程序。那么怎样设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？这就是开放-封闭原则带给我们的答案。
场景：
如：一国两制。这是*上一个伟大的提议。开放的是两制，封闭的是一国。国不可分割，制度可分制。
真希望学校也能充分的用好这种开放-封闭原则啊，那就是：学生只要可以在最后考试中及格，就可以不强制去上课，哈哈。不变的是最后结果，变的是学习过程。真是一举数得啊~
how：
全力以赴是必须，两手准备也是灵活的体现。就是在追求事物的时候，坚持一面不变，同时也要在其他方向做出努力！这种原则也同样使用于生活。
依赖倒转原则（DIP）
what：
1. 高层模块不应该依赖于底层模块，两个都应该依赖抽象。
2. 抽象不应该依赖细节，细节应该依赖于抽象。
说白了，就是针对接口编程，不要对实现编程。
why：
如果我们将高层模块依赖了低层模块，那么想再次利用高层模块时，就没有办法复用了，因为高层模块是与低层模块的访问数据库绑在一起的。如果都依赖与抽象，也就是接口或抽象类，那么只要接口是稳定的，更改任何一个模块都不会造成影响，
场景：
PC里如果CPU, 内存，硬盘都需要依赖具体的主板，那么主板一坏，所有的部件都不能用了，这显然不合理。反过来，如果内存坏了，也不应该造成其他部件不能用。
还有就像我们的手机一样，如果你的手机只能用原装的一个充电器，是不是当你的充电器坏了的时候，你的手机就再也不能用了。那岂不是有很大的损失？所以只要咱们的手机充电接口不坏，就可以换成任何一个匹配的充电器。
how：
依赖倒转可以说是面向对象设计的标志了，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就升级面向对象的设计，反之则是过程化的设计了。
里氏代换原则（LSP）
what：
白话：一个软件实体如果使用的是一个父类的话，那么一定适用于其他子类，而且它觉察不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成它的子类，程序的行为没有变化。
简单来说：子类型必须能够替换掉它们的父类型。
这就好像是继承时理解的概念
why：
只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为。
场景：
问题：在面向对象设计时，一个是鸟类，一个是企鹅类，如果鸟是可以飞的，而企鹅不会飞，那么企鹅是鸟吗？它可以继承鸟类吗？
答案：不能。
因为企鹅没有鸟会飞的这个属性。要想继承，必须会飞。。。
如：动物都可以吃，跑，还有毛。猫，狗，猴都属于动物，它们都有动物类的属性。但是三个动物又分别增加了自己新的行为，比方猴子爱吃香蕉，狗爱叫，猫的眼睛是蓝色等等。
how：
正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展。也就是有了里氏代换原则才使得开放-封闭成为了可能性。
迪米特法则（LOD）
what：
迪米特法则根据字面难以推敲出什么意思，1987年秋天由美国Northeastern University的Ian Holland提出，被UML的创始者之一Booch等普及。后来，因为在经典著作《 The Pragmatic Programmer》而广为人知。
它又叫做最少知识原则。如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
它首先强调的前提是：在类的结构设计上，每一个类都应该尽量降低成员的访问权限。也就是说，一个类包装好自己的private状态，不需要让别的类知道字段或行为就不要public。
迪米特法则的核心思想是强调了类之间的松耦合。
why：
类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。
信息的隐藏促进了软件的复用。
场景：
就像弹钢琴学习即兴伴奏一样。如果将学科比作类：乐理类，和声类，自弹自唱类，即兴伴奏类。如果这四个学科之间没有联系，那么就算我的乐理学的不好，那么我的即兴伴奏好好听讲，也是可以学会的；但是同样，如果这四个学科之间的联系非常大，如果我学不会乐理，我学习和声就困难，我学习和声困难，即兴伴奏就无法进行。
当然了，这种学科之间的联系是必定有的。但是我们在写程序时，就完全可以避免这种高度耦合。
how：
降低代码的耦合度
接口隔离原则
what：
一个类对另外一个类的依赖应该建立在最小接口上。即建立单一接口，只建立需要的，剔除多余的。
why：
- 一个接口代表一个角色，不应当将不同的角色都交给一个接口。没有关系的接口合并在一起，形成一个臃肿的大接口，这是对角色和接口的污染。
- “不应该强迫客户依赖于它们不用的方法。
场景：
现在有个manage类，要管理两种工人worker，worker都需要工作和吃饭。一类是正常人，工作+吃饭；一类是机器人：工作+吃饭。但是我们都知道机器人是不需要吃饭的，但这里却强迫了它吃饭，所以违背了接口隔离原则。那么我们就可以将这两类分离成2个接口，这样机器人不仅可以不吃饭，还可以增加自己的功能：充电。。。
how：
分离接口。
后记
本来对这些原则模糊不清，写完博客后真的是豁然开朗。边学习边总结，边总结边学习，利用好工具，站在巨人的肩膀上。
初步相识，设计模式六大原则你好！