设计模式原则

设计模式原则

设计模式原则的分享

设计模式原则跟我们生活中的物理定律有点类似，有适用范围(比如在爱因斯坦的相对论中，物体的质量随着速度的增大而增大，但是低速时，可以认为不变)，在适用范围内是可以重复，多次发生，每次都可以得到相同，相对稳定的结果。 原则应该有通用性，是一个抽象。在很多地方都可以用类似的东西去考虑(比如我们设计包的时候应该也会考虑到单一职责的问题)

单一职责原则

只有一个原因可以引起他发生变化

1. 我们更喜欢从业务逻辑上去思考，他们放在一起是否合适。
2. 从这个角度去考虑的时候，大家更容易找到，和看懂相互的代码
3. 我自己觉得他跟迪米特法则一起考虑
4. 只放自己相关的东西，不相关的东西不要放

里氏替换原则

在所有可以引用基类的地方都必须可以透明的引用子类。

1. 既然有继承关系，那么从逻辑上他们应该是通用的，而不能出现例外的情况
2. 删除掉MxWebClientView看看效果

依赖倒转原则

1. 高层模块不应该依赖于底层模块，他们都应该依赖于抽象模块
2. 抽象不应该依赖于细节
3. 细节应该依赖于抽象
4. 删除掉MxWebClientView后，引用了很多方法是MxWebClientView的。

接口隔离原则

接口越小越好

1. 跟单一职责有关系
2. 云服务提供的回调接口可以作为反例

迪米特法则

只跟自己的朋友说话

1. 对外的接口越少越好，那么朋友就越少，越容易明白这个类的关系。
2. 应该不可能所有类都要做的是朋友越少越好，总有一个跟各个类产生关系的。但是最好只有一个
3. 最好别跟自己朋友的朋友发生什么关系。

开闭原则

对扩展开放，对修改关闭

1. 需要以上的几个原则的支持
2. 有了里氏替换，才能通过设置不同的子类来完成不同的实现，在进行扩展的时候可以做到非常方便
3. 有了依赖倒转，才能在实现发生改变时，因为依赖于抽象，那么框架代码不用发生修改，只需要进行设置或者修改具体实现，来改变行为。