学习设计模式笔记

﹏ヽ暗。殇╰゛Y 2022-08-20 07:16 140阅读 0赞

# 学习设计模式笔记 #

> 抱歉，还是要啰嗦一句：其实学习本来就不是易事，我写这篇文章的初衷也是希望大家学习起来更加轻松，充满乐趣。但是千万！千万不要把看的文章收藏起来，或是存下地址，心里想着：以后有时间再看。这样的例子太多了，也许几年后你都没有再打开这个页面。

## 设计模式六大原则 ##

1.  单一职责原则：一个类只负责单一的职责。只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则。[单一职责原则][Link 1]
2.  里氏替换原则：子类可以扩展父类的功能，但不能改变父类原有的功能。**使用继承会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。**[里氏替换原则][Link 2]
3.  依赖倒置原则：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。**相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。**[依赖倒置原则][Link 3]
4.  接口隔离原则：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。**接口是设计时对外部设定的“契约”，通过分散定义多个接口，可以预防外来变更的扩散，提高系统的灵活性和可维护性。**[接口隔离原则][Link 4]
5.  迪米特法则：一个对象应该对其他对象保持最少的了解。**陌生的类最好不要作为局部变量的形式出现在类的内部。迪米特法则的初衷是降低类之间的耦合，由于每个类都减少了不必要的依赖，因此的确可以降低耦合关系。但是凡事都有度，虽然可以避免与非直接的类通信，但是要通信，必然会通过一个“中介”来发生联系，例如本例中，总公司就是通过分公司这个“中介”来与分公司的员工发生联系的。过分的使用迪米特原则，会产生大量这样的中介和传递类，导致系统复杂度变大。所以在采用迪米特法则时要反复权衡，既做到结构清晰，又要高内聚低耦合。**[迪米特法则][Link 5]
6.  开闭原则：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。**在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。**当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。**开闭原则无非就是想表达这样一层意思：用抽象构建框架，用实现扩展细节。因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节，我们用从抽象派生的实现类来进行扩展，当软件需要发生变化时，我们只需要根据需求重新派生一个实现类来扩展就可以了。当然前提是我们的抽象要合理，要对需求的变更有前瞻性和预见性才行。**[开闭原则][Link 6]

[Link 1]: http://blog.csdn.net/zhengzhb/article/details/7278174
[Link 2]: http://blog.csdn.net/zhengzhb/article/details/7281833
[Link 3]: http://blog.csdn.net/zhengzhb/article/details/7289269
[Link 4]: http://blog.csdn.net/zhengzhb/article/details/7296921
[Link 5]: http://blog.csdn.net/zhengzhb/article/details/7296930
[Link 6]: http://blog.csdn.net/zhengzhb/article/details/7296944