模式-工程化实现及扩展读书笔记——设计原则

一.SRP (single responsiblity principle)单一职责原则

1.说明：

每个类只有一个职责，即只能有一个引起它变化的原因；

2.理解：

（1）由于每个类只有一个职责，这样就解除或削弱了不同类之间的功能耦合；

（2）在一个类中集合太多的功能，会影响它的“稳定性”；

（3）在一个类中有太多功能，对于日后的维护会造成很大的困扰，使得软件对于“改变”的包容性变差，我想这是主要的原因；

但是在现实中要满足这个原则比较困难，在编码过程中你会不自觉地为一个添加各种各样的功能，在某些情况下这是由于开发周期及自己的懒惰共同作用的结果。但是在实际项目中我们要把握好“度”的问题，过分执着于这个原则将会造成“类爆炸”，同样不利于维护。在设计时 ，要考虑到成本与可能性，如果某几个功能相似且变化的可能性较低，不妨将它们封装在一起，这样成本会更小一些。

 

二.LSP 里氏代换原则

1.说明

所有的子类都能替换它的超类；

2.理解

这个原则在java中的继承中有了明确的体现，在子类中将变化进行封装，然后用于替换它的超类，这样完成了软件功能的“变化”；

 

三.DIP 依赖倒置原则

1.说明

（1）依赖于抽象而非具体；

（2）高层与底层不应相互依赖，而应该依赖于抽象；

2.理解

（1）在说明（2）中的高层与底层就是所谓的“具体”，在实际中“抽象”往往为一个接口；这样的依赖可以保证高层与底层可以遵循着某一原则相互变化，而这一“原则”就是它们依赖的抽象；

（2）写到这里我仿佛看到了设计模式的精髓所在，那就是便于维护与修改，这才更加符合软件工程中“工程”的概念；所谓的封装“变化”并不是设计的模式的终极目标，对于这个易变的工程，维护变化才是最为重要的一条原则，如果我们编写软件然后永远不做修改，那么我想程序员的工作会更加容易得多O(∩_∩)O~。

 

四.ISP 接口隔离法则

1.说明

一个类对于另一个类的依赖应建立在最小的接口之上；

2.理解