设计模式之六大原则

设计模式之设计原则

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

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 方法

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

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

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

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

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

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

迪米特法则

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

开闭原则

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