设计模式--6个设计原则

1、单一原则

简单定义：一个类只负责一个一项职责。

解决办法：当遇到违反单一职责的情况时，最直观的做法就是—
a) 将原来的类分成两个或者多个类；推荐
缺点：就是开销增大了，体现在：①分解类开销，②客户端修改开销
所以，有时为了某些要求，也会违反单一职责原则，如下，
b）修改相应的职责方法；
优点：特别简单（面向过程）
缺点：一旦职责发生变化，就需要不停的修改该方法
c）给当前类添加一个或多个新的方法；
优点：方法还是遵循单一职责原则，而且原来的方法不需要修改
缺点：可能造成方法过多，情况变复杂。

注意事项：所以在类简单，方法少的情况下可以违背单一原则，否则，还是遵守的好，没有绝对的单一职责，一旦需求变更，职责粒度分细，原来的符合单一职责的也会因此而不符合单一原则。
适用范围：面向对象以及面向模块设计。

2、里式替换原则

（源于一个来自买买提学院姓里的一个女士提出来的一套理论）
简答定义：每个引用基类的地方都必须能够透明引用其子类的对象。
—-也就是说，尽量不要重载父类中已经实现的方法，这样不至于导致原有父类的功能异常。

解决办法：子类不要重新父类已经实现了的方法，如果要重新父类的该方法，选用依赖、聚合、组合等关系代替。
其深层含义体现在：
1）子类不能覆盖父类的非抽象方法；
2) 当子类重载父类方法时，形参输入参数更加宽松；eg. int →double
3) 当子类 方法重载父类方法，返回值要比父类更加严格。
口诀：‘’前松后紧‘’。。

注意事项：遵守这一原则可以最大程度的代码功能保证不会出现错误，其他不做要求。

3、依赖倒置原则—“面向接口编程”

定义：高层模块不依赖于底层模块，二者都需要依赖于他们的抽象； 细节应该依赖于抽象，而不是反过来。

解决办法：让底层类们实现接口或者抽象类，让原来依赖底层类的通过接口与底层类发生练习。（如下图所示，A依赖于B,然后又依赖于C, A可以通过接口I和B，C发生联系）

注意事项：变量声明类型尽量使用抽象类和接口，底层也是如此，继承时当然需要遵守里氏
替换原则。

4、接口隔离原则—“分解细化接口”

定义：客户端不应该依赖他不要的接口，也就是说依赖建立在最小接口上。

解决办法：将原有的接口拆分为几个分散的接口。

注意事项：
1）不要过度分解，造成接口混乱。
2）为依赖接口的类分配其需要的方法，不要暴露其他方法（隐藏起来），提高高内聚，减少对外交互。
3）接口隔离与单一职责不同，一个注重细节实现，一个注重整体。

5、迪米特原则—最少知道

定义：类与类之间的耦合越低越好。（涉及到具体业务就是架构中的分层原理，相邻的层之间有关联，不要和非相邻层过于耦合，相邻的特点体现为：出现对应类的成员变量、方法参数、方法返回值，而非局部变量）

解决办法：利用public对外公布必须的方法，其他不做公布，

注意事项：降低耦合度需要慎重，具体情况中，适量即可，别为了符合最少知道原则，做很复杂的中介（或者说分层），早曾系统复杂/结构不够清晰。

6、开闭原则

定义：软件在升级维护等过程中，由于需要对软件的代码进行修改，这往往会对旧有代码引入错误，这样就要对整个功能进行重构，对原有代码都要进行测试。

解决办法：扩展为主，修改为辅，即就是抽象构建整体，实现扩展细节，扩展时通过派生一些类去实现，而非修改去实现。

注意事项：对抽象构建整体要求高，需要一定的前瞻性，

总结如下：
1. 单一职责 实现职责单一
2. 里氏替换 继承结构不可破坏
3. 依赖倒置 面向接口
4. 接口隔离 接口设计精简
5. 最少知道 类之间的耦合要低
6. 开闭原则 扩展可以，修改拒绝