设计模式6大设计原则

6大设计原则

单一职责原则

Single Responsibility Principle简称SRP

定义

​ 应该有且仅有一个原因引起类的变更

好处

  • 类的复杂性降低,实现什么职责都有清晰明确的定义;
  • 可读性提高,复杂性降低,那当然可读性提高了;
  • 可维护性提高,可读性提高,那当然更容易维护了;
  • 变更引起的风险降低,变更是必不可少的,如果接口的单一职责做得好,一个接口修改只对相应的实现类有影响,对其他的接口无影响,这对系统的扩展性、维护性都有非常大的帮助。

适用范围

  • 适用于接口、类,同时也适用于方法

实例

修改用户信息void changeUser(IUserBO, UserBO, String..changeOpyions),根据传递的类型不同,把可变长度参数changeOptions修改到userBO这个对象上,并调用持久层的方法保存到数据库中

拆分为

  • void changeUserName(String username)
  • void changeHomeAddress(String homeaddress)
  • void changeOfficeTel(String officetel)

changeUser方法职责不清晰,不单一;拆分成许多接口,每个方法的职责非常清晰明确,不仅开发简单,而且日后的维护也非常容易

里氏替换原则

Liskov SubstitutionPrinciple----LSP

继承

优点

  • 代码共享,减少创建类的工作量,每个子类都拥有父类的方法和属性;
  • 提高代码的重用性;
  • 子类可以形似父类,但又异于父类,“龙生龙,凤生凤,老鼠生来会打洞”是说子拥有父的“种”,“世界上没有两片完全相同的叶子”是指明子与父的不同;
  • 提高代码的可扩展性,实现父类的方法就可以“为所欲为”了,君不见很多开源框架的扩展接口都是通过继承父类来完成的;
  • 提高产品或项目的开放性。

缺点

  • 继承是侵入性的。只要继承,就必须拥有父类的所有属性和方法;
  • 降低代码的灵活性。子类必须拥有父类的属性和方法,让子类自由的世界中多了些约束;
  • 增强了耦合性。当父类的常量、变量和方法被修改时,需要考虑子类的修改,而且在缺乏规范的环境下,这种修改可能带来非常糟糕的结果——大段的代码需要重构。

定义

  • 第一种定义,也是最正宗的定义:If for each object o1 of type S there is an object o2 oftype T such that for all programs P defined in terms of T,the behavior of P is unchangedwhen o1 is substituted for o2 then S is a subtype of T.(如果对每一个类型为S的对象o1,都有类型为T的对象o2,使得以T定义的所有程序P在所有的对象o1都代换成o2时,程序P的行为没有发生变化,那么类型S是类型T的子类型。)
  • 第二种定义:Functions that use pointers or references to base classes must be able touse objects of derived classes without knowing it.(所有引用基类的地方必须能透明地使用其子类的对象。)
  • 第二个定义是最清晰明确的,通俗点讲,只要父类能出现的地方子类就可以出现,而且替换为子类也不会产生任何错误或异常,使用者可能根本就不需要知道是父类还是子类。但是,反过来就不行了,有子类出现的地方,父类未必就能适应。

含义

  • 1.子类必须完全实现父类的方法
  • 2.子类可以有自己的个性
  • 3.覆盖或实现父类的方法时输入参数可以被放大
  • 4.覆写或实现父类的方法时输出结果可以被缩小

优点

采用里氏替换原则的目的就是增强程序的健壮性,版本升级时也可以保持非常好的兼容性。即使增加子类,原有的子类还可以继续运行。在实际项目中,每个子类对应不同的业务含义,使用父类作为参数,传递不同的子类完成不同的业务逻辑,非常完美!

依赖倒置原则

Dependence Inversion Principle------DIP

定义

High level modules should not depend upon low level modules.Both should dependupon abstractions.Abstractions should not depend upon details.Details should dependupon abstractions.

  • 模块间的依赖通过抽象发生,实现类之间不发生直接的依赖关系,其依赖关系是通过接口或抽象类产生的;
  • 接口或抽象类不依赖于实现类;
  • 实现类依赖接口或抽象类。
  • 更加精简的定义就是“面向接口编程”——OOD(Object-Oriented Design,面向对象设计)的精髓之一。

优点

可以减少类间的耦合性,提高系统的稳定性,降低并行开发引起的风险,提高代码的可读性和可维护性。

应用

TDD(Test-Driven Development,测试驱动开发)开发模式

依赖的三种写法

  • 1.构造函数传递依赖对象
  • 2.Setter方法传递依赖对象
  • 3.接口声明依赖对象

最佳实践

  • 每个类尽量都有接口或抽象类,或者抽象类和接口两者都具备
  • 变量的表面类型尽量是接口或者是抽象类
  • 任何类都不应该从具体类派生
  • 尽量不要覆写基类的方法
  • 结合里氏替换原则使用

接口隔离原则

接口类型

实例接口

实例接口(Object Interface),在Java中声明一个类,然后用new关键字产生一个实例,它是对一个类型的事物的描述,这是一种接口。比如你定义Person这个类,然后使用PersonzhangSan=new Person()产生了一个实例,这个实例要遵从的标准就是Person这个类,Person类就是zhangSan的接口。

java类就是一个接口

类接口

Java中经常使用的interface关键字定义的接口

隔离

  • Clients should not be forced to depend upon interfaces that they don't use.(客户端不应该依赖它不需要的接口。)

  • The dependency of one class to another one should depend on the smallest possibleinterface.(类间的依赖关系应该建立在最小的接口上。)

  • 建立单一接口,不要建立臃肿庞大的接口

  • 接口尽量细化,同时接口中的方法尽量少。

与单一职责原则的联系

接口隔离原则与单一职责的审视角度是不相同的,单一职责要求的是类和接口职责单一,注重的是职责,这是业务逻辑上的划分,而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法,这10个方法都放在一个接口中,并且提供给多个模块访问,各个模块按照规定的权限来访问,在系统外通过文档约束“不使用的方法不要访问”,按照单一职责原则是允许的,按照接口隔离原则是不允许的,因为它要求“尽量使用多个专门的接口”。专门的接口指什么?就是指提供给每个模块的都应该是单一接口,提供给几个模块就应该有几个接口,而不是建立一个庞大的臃肿的接口,容纳所有的客户端访问。

规范约束

  • 接口要尽量小,但不能违反单一职责原则
  • 接口要高内聚
  • 定制服务

迪米特法原则

迪米特法则(Law of Demeter,LoD)也称为最少知识原则(Least Knowledge Principle,LKP)

规则

一个对象应该对其他对象有最少的了解。通俗地讲,一个类应该对自己需要耦合或调用的类知道得最少,你(被耦合或调用的类)的内部是如何复杂都和我没关系,那是你的事情,我就知道你提供的这么多public方法,我就调用这么多,其他的我一概不关心。

含义

  • 只和朋友交流
  • 朋友间也是有距离的
  • 是自己的就是自己的
  • 谨慎使用Serializable

开闭原则

定义

Software entities like classes,modules and functions should be open for extension butclosed for modifications.(一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。)

  • 软件实体应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。

软件实体

  • 项目或软件产品中按照一定的逻辑规则划分的模块。
  • 抽象和类。
  • 方法。

为什么要采用开闭原则

  • 开闭原则对测试的影响
  • 开闭原则可以提高复用性
  • 开闭原则可以提高可维护性
  • 面向对象开发的要求

如何使用开闭原则

  • 抽象约束
  • 元数据(metadata)控制模块行为
  • 制定项目章程
  • 封装变化

使用注意事项

  • 开闭原则也只是一个原则
  • 项目规章非常重要
  • 预知变化,拥抱变化