设计模式（二）设计原则

设计模式以以下原则为指导：

• 开闭原则
• 单一职责原则
• 里氏替换原则
• 依赖倒置原则
• 接口隔离原则
• 迪米特法则

开闭原则OCP Open Close Principle

一个软件实体应当对扩展开放，对修改关闭。

这个很难理解，听到就一头雾水。啥是扩展？啥是修改？啥是开放？啥是关闭？根本不是人话。。。
看了很久才理解一点点：我们在架构的时候，要考虑到后续的扩展，但是尽量不要去修改原来的接口。

说的轻松，但是怎么实现呢？那就是后面的原则。

单一职责原则SRP Single Responsibility Principle

一个类，应当只有一个引起它变化的原因；即一个类应该只有一个职责。

很讨厌这些不说人话的话。
简单说，一个类就做一件事，做自己的事。其他合他无关的事，就不管。
我是显示器，我绝对不管鼠标键盘。这样，当修改鼠标的时候，我也不用操心。不用修改我，更不会担心我被改坏。

里氏替换原则LSP Liskov Substitution Principle

如果对一个类型为S的对象o1，都有类型为T的对象o2，使得以S定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T是类型S的子类型。

嗯，这个数学式的定义确实很牛逼，严谨又专业。但是我还是不晓得他说的啥玩意。o1,o2，什么P、ST，弄得人倒像个SB。。。
人话是这么说的：要确保，程序里的使用父类的地方，全部都可以换成子类。 这样子类的使用和定义才是正确的。
里氏替换原则是MIT计算机科学实验室的Lisov女士在1987年提出的。
一般来说，这一点编译器都帮忙做好了。如果子类有什么出格的事，根本编译不过。所以，我觉得对于java和C++来说，这个似乎不用太在意。

依赖倒置原则 DIP Dependence Inversion Principle

■ 高层模块不应该依赖低层模块，两者都依赖其抽象；
■ 抽象不依赖细节；
■ 细节应该依赖于抽象。

这是一个很有用的原则。一般来说，高层模块必须依赖底层才能工作。比如打开电视机，高层的按钮必须依赖底层的开关电路。依赖倒置的意思是，将两者隔开：开关不要直接依赖底层电路。
注意，我将直接两个字加粗了。不是不依赖，不依赖就没法工作了。而是不直接依赖。
将开关的接口抽象化，调用抽象的接口。
这里需要使用一个技巧：根据使用者的方式来定义接口，而不是根据实现者来定义接口。
传统的方式：
爷爷----驾驶汽车
依赖倒置原则：
爷爷—司机—驾驶汽车

可以看到，爷爷并不依赖汽车，他只需要给司机发消息，告诉司机去哪里即可。这样，即便更换汽车，甚至更换交通工具为摩托车，飞机，爷爷都不需要进行修改。
这样，当我们移植时，只要提供的接口层不变，应用可以完全不用修改，所以可以达到接口屏蔽的目的。

接口隔离原则ISP Interface Segregation Principle

客户端不依赖它不需要的接口
类之间的依赖应当尽量最少

接口隔离原则，就是简洁的封装。
第一，不提供使用者不需要的接口。比如，下面的遥控器对比：

前一图中的遥控器，提供了更多的接口.如果仅仅是在选择界面，其余的按键就是多余的。对于用户很少用，甚至不用的接口，需要考虑取消。这样，在移植和修改、测试的时候，都可以快速稳定。

对于同一个类的不同使用者，接口也不应该一样。比如，对于一个成绩单，老师有修改的接口，但是学生只能有查询的接口。我们可以通过基类，或者java接口来实现这一点。

第二，一个接口只代表一个单一的功能，遵从单一原则。比如，调节音量时一个接口，关闭灯光是一个接口。如果弄到一起，就不容易使用，修改和维护。

迪米特法则LoD Law of Demeter

一个对象应该对其他对象知道的最少。

可以不了解的接口，不要耦合进来。不难理解，如果知道了不必要知道的接口，这个接口被使用之后，如果发生修改，那么将修改一大片使用该接口的地方。

总结

可以看到，六大原则实际是有重合的地方。并且，都始终围绕着，单一职责，最简接口，最少改动的要点，从而达到容易使用、修改和维护的目的。

• 开闭原则
  总则，更新和维护少修改原来的代码，多通过扩展进行。
• 单一职责原则
  每个类，每个函数，每个接口，只做一件事。
  
  
  
• 里氏替换原则
  考虑使用继承，还是组合。
  
  
• 依赖倒置原则
  类之间的调用，用接口或者抽象类来进行。不直接依赖底层的实现。
  
  
  
• 接口隔离原则
  同一类，面对不同客户，提供不同的方法。通过抽象类或接口实现。
  
• 迪米特法则
  类之间的调用，不要过多的耦合不必要的信息。让别人去做事，拿到结果就好了，自己不要亲自去做。
  
  

后续的设计模式实例中，我们会逐渐加深这些原则的理解。