设计模式之(依赖倒置、接口隔离、迪米特、开放封闭)

731 阅读6分钟
2019.07.09:要相信你要的,迟早会给你的。

 

三、依赖倒置原则

依赖倒置原则(Dependence Inversion Principle,DIP)
包含三层含义:
  1. 高层模块不应该依赖底层模块,两者都应该依赖抽象;
  2. 抽象不应该依赖细节;
  3. 细节应该依赖抽象。
依赖倒置原则在Java语言中的表现就是:
  1. 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;
  2. 接口或抽象类不依赖于实现类;
  3. 实现类依赖接口或抽象类。
对象的依赖关系有三种方式来传递:
  1. 构造函数传递依赖对象 --- 在类中通过构造函数声明依赖对象,按照依赖注入的说法,这种方式叫做构造函数注入。
  2. Setter方法传递依赖对象 --- 在抽象中设置Setter方法声明依赖关系,依照注入的说法,这是Setter依赖注入。
  3. 在接口的方法中声明依赖对象,这种方式也叫做接口注入
怎么在项目中使用这个规则:
  1. 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备; --- 这是依赖倒置的基本要求,接口或抽象类都是属于抽象的,有了抽象才可能依赖倒置。
  2. 变量的表面类型尽量是接口或者是抽象类;
  3. 任何类都不应该从具体类派生;
  4. 尽量不要覆写基类的方法; --- 如果基类是一个抽象类,而且这个方法已经实现了,子类尽量不要覆写。类间依赖的是抽象,覆写了抽象方法,对依赖的稳定性会产生一定的影响。
  5. 结合里氏替换原则使用。 --- 接口负责定义public属性和方法,并且声明与其他对象的依赖关系,抽象类负责公共构造部分的实现,实现类准确的实现业务逻辑,同时在适当的时候对父类进行细化。

四、接口隔离原则

接口分为两种:
  1. 实例接口(Object Interface),在Java中声明一个类,然后用new关键字产生一个实例,它是对一个类型的食物的描述,这是一种接口。
  2. 类接口(Class Interface),Java中经常使用的interface关键字定义的接口;
包含4层含义:
  1. Clients should not be forced to depend upon interfaces that they don‘t use。(客户端不应该依赖它不需要的接口。)接口的设计粒度越小,系统越灵活,接口设计要有限度的。
  2. The dependency of one class to another one should depend on the smallest possible interface。(类间的依赖关系应该建立在最小的接口上。)接口要尽量小; --- 这是接口隔离原则的核心定义,不出现臃肿的接口(Fat Interface),但是“小”是有限度的,首先就是不能违反单一职责原则。
  3. 接口要高内聚; 高内聚就是提高接口、类、模块的处理能力,减少对外的交互。在接口中尽量少公布public方法,接口是对外的承诺,承诺越少对系统的开发越有利,变更的风险也就越少,同时也越有利于降低成本。
  4. 定制服务。一个系统或系统内的模块之间必然会有耦合,有耦合就要有相互访问的接口(并不一定就是Java中定义的Interface,也可能是一个类或单纯的数据交换),我们设计时就需要为各个访问者(即客户端)定制服务。定制服务就是单独为一个个体提供优良的服务,只提供访问者需要的方法。
接口隔离原则是对接口的定义,同时也是对类的定义,接口和类尽量使用原子接口或原子类来组装。

五、迪米特法则

迪米特法则(Law of Demeter ,LoD)也称为最少知识原则(Least Knowledge Principle,LKP)
通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心。
包含以下4层含义:
  1. 每个对象都必然会与其他对象有耦合关系,一个类只和有耦合关系的交流。
  2. 一个类公开的public属性或方法越多,修改时涉及的面积越大,变更引起的风险扩散也就越大。
  3. 是自己的就是自己的 。 如果一个方法放在本类中,即不增加类间的关系,也对本类不产生负面影响,就放置在本类中。
  4. 谨慎使用Serializable
迪米特法则的核心观念就是类间解耦,弱耦合,只有弱耦合了以后,类的复用率才可以提高。其要求的结果就是产生了大量的中转或跳转类,导致系统的复杂性提高,同时也为维护带来了难度。迪米特法则要求类间解耦,但解耦是有限度的。
六、开放封闭原则
开放封闭原则的定义:Software entities like classes, modules and functions should be open for extension but closed for modifications.(一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。)其含义是说一个软件实体应该通过扩展来实现变化。
一个软件项目包括以下几个部分:
  1. 项目或软件产品中按照一定的逻辑规则划分的模块。
  2. 抽象和类。
  3. 方法。
开放封闭原则对扩展开放,对修改封闭,并不意味着不做任何修改,低层模块的变更,必然要有高层模块进行耦合,否则就是一个孤立无意义的代码片段。我们可以把变化归纳以下三种类型:
  1. 逻辑变化。 只变化一个逻辑,而不涉及其他模块。
  2. 子模块变化。 一个模块变化,会对其他的模块产生影响,特别是一个低层次的模块变化必然引起高层次模块的变化,因此在通过扩展完成变化时,高层次的模块修改是必然的。
  3. 可见视图变化 。可见视图是提供给客户使用的界面,界面的修改引起的变化,但还是可以通过扩展来完成变化,这就要看我们原有的设计是否灵活。
前五个原则就是指导设计的工具和方法,而开闭原则才是其精神领袖。换一个角度理解,依照Java语言的称谓,开闭原则是抽象类,其他五大原则是具体的实现类,