设计模式笔记之6原则--为“变化”做好准备

1. 单一职责原则： 就是每个类 或者 函数方法 只负责一个逻辑功能或者说逻辑单元，很好理解的。但是要注意的就是要注意划分的粒度。

2. 里氏替换原则：每个可以用父类的地方，都可以用子类。如果一个函数接受某个类的父类作为参数，那么传入该类的子类一定也可以。实际上从语言的层面，这条规则也是满足的。但是这里要求的实逻辑不出bug。其实就是要去，子类要实现父类所有的方法，同时也慎重覆盖父类的方法，做的不好就会导致逻辑bug。

3 接口隔离原则：还有一个名字更形象叫最少知识原则，就是不要告诉我不需要的信息，只要告诉我我必须知道的消息。这样就将依赖降到最低程度。就是功能最小粒度拆分，当然也不能太小了。加入有一个类他只是处理可以飞行的物体，那么只要传入flyable 接口，而不要传入 bird 接口，因为bird 还包含 walkable 接口。所以设计的时候，要将相应的类进行接口拆分，使用的时候用哪个就传哪个。

4. 依赖倒置原则：高层代码要依赖抽象，也不要依赖具体细节。这样的好处，就是利于并行开发，接口定义好了，就可以各自做自己的工作。同时接口定义好了，后面扩展也方便，不影响上层代码。

5. 迪米特法则： 只和朋友对话，朋友就是 函数的参数，或者函数返回类，或者成员变量。这条法则要求高内聚，低耦合。类的内部不要出现不适朋友的类。

6. 开闭原则： 就是对扩展开发，对修改关闭。其实这个比较好理解，一个运行很久的代码，经过了实践的检验，那么就不要去改它了，可以去扩展他。还有改类会导致牵一发动全身的风险。换句话说，在变化发生的时候，是通过扩展的方式来修改，而不是通过修改的方式来扩展。

总结：程序或者一个系统开发出来，随着时间的推移肯定是需要不断的更新，不断的修改，那么程序的设计就必须为这些变化做准备，随时准备迎接变化，主要是目前不可以预知的变化，那么我们就尽量做到当变化发生的时候，对原有的系统冲击最小。然而，6大原则 分别从各个角度和各个方面来知道，怎么做可以在发生变化的时候，可以以最小的代价完成更新，同时保证健壮性。核心观点就是要抽象，分离，分而治之，不要过多的纠缠态细节。还有一点就是始终贯彻的，要高内聚，低耦合。