设计模式之六大原则

设计模式之设计原则

这软件设计过程中，有六大设计原则：

1. 单一职责原则
2. 里氏替换原则
3. 依赖倒置原则
4. 接口隔离原则
5. 迪米特法则
6. 开闭原则

由于软件开发过程中，根据业务不同等因素形成了各种复杂的而不可预料的需求，遵守原则，让项目开发过程与维护过程中，减少付出更多的时间与努力而达到更好的实现功能。需要对经验，不断总结，不断实践，对将设计模式使用的更熟练，对软件开发起到意想不到的作用。

以下对六大设计原则，鄙人的一些简单述说：

单一职责原则

定义：
做到有且只有一个原因引起类的变更，也就是说一个接口做一件事，这件事能概况某一事物的某一职责。

问题由来：
类T负责两个不同的职责，职责P1，职责P2，当职责P1需求发生变化时，需要修改P2功能，有可能会导致原本运行正常功能发生故障

解决方案：
将T的P1，P2两个职责使用T1，T2分别完成，T1负责P1功能，T2负责P2功能，当T1发生改变，T2不会发生改变，T2发生改变，T1也不会发生改变。

由于每个职责都进行分开，会出现大量类，当某一职责进行分解时，需要修改大量的代码，此时修改职责类中的代码违反单一职责（代码级别，方法级别），减少大量类出现。

适用情况：

1. 接口
   必要时可以将接口中的属性和行为进行分解，这样可以做到单一职责。
2. 方法
   方法中的参数过多，可以对方法的参数进行分解，可以做到单一职责。

总结：
使用接口和方法的方式，尽量做到只有一个原因引起对这个类的改变。
单一职责原则，不只是面向对象编程，还适合模块化编程等。

在实际项目中，由于功能过于复杂等原因做到该原则，还是挺难的，尽量做到单一职责原则，。

里氏替换原则

定义：
简单点说就是只要父类出现的地方，子类就可以出现，且替换成子类后，也不能出现任何错误与异常（子类出现后，父类不能因为子类的出现导致父类出问题），导致出现错误原因：子类继承父类，重写父类方法后，这时父类方法功能就失效，发生变化。

意义：
子类可以扩展父类的功能，但不能改变父类原有的功能

继承机制的优点：

1. 代码共享，减少创建类的工作量
2. 提高代码的重用性
3. 子类可以形似父类，又异于父类，
4. 提高父类的扩展性，实现父类的方法即可随意而为

缺点：

1. 继承是入侵性的，（拥有父类的所有属性和方法）
2. 降低了代码的灵活性，（由于父类属性的约束，导致子类的约束更多）
3. 增强了耦合性，（当父类的常量，变量，方法被修改，需考虑对子类的影响）

总结： 当违反了里氏替换原则后，可以将父类和子类抽取出更加通用的基类，使用依赖，聚合，组合灯关系，降低继承的缺点。

依赖倒置原则

定义：

1. 高层模块不应该依赖低层模块，两者都应该依赖其抽象
2. 抽象不应该依赖细节
3. 细节应该依赖抽象

在代码中可以理解成：

1. 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或者抽象类产生的
2. 接口或者抽象类不依赖于实现类
3. 实现类依赖于接口或者抽象类

此时可以更简洁的理解成： 面向接口编程

总结：

依赖导致原则本职就是通过抽象（抽象类或者接口）使各个类或者模块实现彼此独立，不相互影响，实现模块的松耦合。

在实际使用项目中，尽量使用如下规则：

1. 每个类尽量都要有接口或者抽象类，或者抽象类和接口都有（依赖倒置原则定义要由抽象才能实现依赖倒置）

2. 变量表面类型尽量是接口或者抽象类

3. 任何类都不应该从具体类派生

4. 尽量不要重写基类已经写好的方法（里式替换原则）

5. 结合里式替换原则来使用（依赖原则和里式原则总结：接口负责定义public属性和方法，并声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确的实现业务逻辑，并在适当的时候对父类进行细化）

接口隔离原则

我们先来看接口的定义 :

实例接口 : 在 Java 中声明一个类,然后用 new 关键字产生一个实例,它是对一类事物的描述,可以看成是一个接口
类接口 : 使用 interface 定义的接口
隔离的的理解 :

1. 客户端不应该依赖它不需要的接口
2. 类之间的依赖关系应该建立在最小的接口上

概括 : 建立单一接口,不要建立臃肿庞大的接口,也就是接口尽量细化,接口中的方法尽量少
这个是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

接口隔离原则的约束条件 :

接口要高内聚,意思就是提高接口,类,模块的处理能力,减少对外的交互,再具体一点就是在接口中尽量减少对外的 public 方法,通过业务逻辑压缩接口中的 public 方法

定制服务,就是单独为一个个体提供优良的服务,比如我们写用户模块的时候,需要给用户提供查询信息,修改密码,注册用户等信息,当管理员执行相同操作的时候,一般人会复用这些方法,

然后在这个的基础上再增加管理员自己的方法,这种设计方法肯定是有问题的,这样设计,当你修改了普通用户调用的接口实现时,管理员的实现也会发生不可预测的改变,我们应该为管理员单独写一个接口

接口设计是有限度的,接口的设计粒度越小,系统越灵活,这是肯定的,但灵活的同时带来的问题是 结构复杂化,开发难度增加, 可维护性降低

一个接口只服务于一个子模块或业务逻辑

已经被污染了的接口,尽量去修改 ,若修改的风险较大,则采用适配器模式进行转化处理

了解环境,拒绝盲从,不要一味的去套设计模式,有的时候不用比用了更好,也不要去照搬别人的设计方法,他的方法到你这不一定效果就好,毕竟业务逻辑不一样

迪米特法则

定义 : 迪米特法则也叫最少知识原则,含义是 一个对象应该对其他对象有最少的了解,这个应该很好理解,就是降低各模块之间的耦合

开闭原则

定义 : 一个软件实体如类,模块和函数应该对扩展开放,对修改关闭,开闭原则也是其他五个原则的基石