设计模式原则的开闭原则的理解

开闭原则

即Open Closed Principle,它是最基础也是最重要的设计原则,我们遵循其它的设计原则如单一职责原则、依赖倒置原则、里氏替换原则等最终都是为了开闭原则。

开闭原则要求一个软件实体,如类、函数或模块,要对扩展开放(提供方),对修改关闭(使用方)。当有一个新的功能或需求来了时,我们应该是通过增加新的类、函数、模块等手段来代替直接修改原来的类或函数。

总之一句话就是用抽象构建框架,用实现扩展细节

案例

重构前UML图

重构前UML图

代码1

现在若要增加一个统计平台拼多多,那就需要在yearSales方法里增加if else判断分支,另外调用方的客户端也要跟着修改,这就违背了开闭原则。根据对修改关闭,对扩展开放的宗旨,我们需要这样改。

代码2

 

 

0

设计模式原则的接口隔离原则的理解

设计模式里有很多原则,今天就记录一下自己对设计模式原则的接口隔离原则的理解。

接口隔离原则

Interface Segregation Principle,即ISP。客户端不应该被迫实现一些它们用不到的接口。我们需要把胖接口分组,用多个细分的接口代替它,每个接口只服务于一个子模块,或者只提供一种功能。

案例

有一个设备事件接口DeviceEvent,里面有分别是设备开启、设备关闭、设备报警、开灯、改变温度这5个方法。Light类和Temperature类分别实现了这个接口,LightUse类依赖了Light类的turnOn()、turnOff()、turnColor()方法。TemperatureUse类依赖了Temperature类的turnOn()、turnOff()、changeTemperature()方法。

重构前UML图

重构前UML图

重构前代码

存在的问题

1.Light类实现了DeviceEvent接口的alarm()和changeTemperature()方法,但确没有具体实现逻辑,因为它不需要这两个方法。同理,Temperature类也是一样,也有两个空方法。相当于多出来的空方法是强加给他们的。

2.DeviceEvent接口职责不清晰,不能笼统的让Light类和Temperature类实现它。

3.如果现在又增加了一种声控设备,那又会影响到Light类和Temperature类。

使用接口隔离原则进行重构

重构后的UML图

重构后UML图

重构后代码

接口隔离原则的重点

1.一个类对另外一个类的依赖应该是建立在最小接口上的。不强迫接口实现类实现它们不需要的接口(出现空方法)。同时也可降低不同客户间的影响。

2.客户端程序不应该依赖它不需要的接口方法。

3.过于臃肿的接口设计是对接口的污染。

 

 

0

设计模式里的责任链模式的实际应用

前言

责任链模式(Chain of Responsibility Pattern)为请求创建了一个接收者对象的链。这种模式给予请求的类型,对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。

在这种模式中,通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求,那么它会把相同的请求传给下一个接收者,依此类推。

使用责任链模式是避免请求发送者与接收者耦合在一起,让多个对象都有可能接收请求,将这些对象连接成一条链,并且沿着这条链传递请求,直到有对象处理它为止。

实际使用

一个事件需要经过多个对象处理是一个挺常见的场景,譬如检验系统的检验流程。

电梯的检验流程
起重机检验流程

代码

github地址:https://github.com/shaweiwei/mall-tiny-docker-file

整体图
抽象流程处理类AbstractProcessHandler
每个流程步骤对应的处理类
两个枚举类
service类和实现类
DTO类
Controller类
启动类
application.yml

启动后用postman测试

先测试电梯检验流程
再测试起重机检验流程

总结

责任链的代码核心是nextHandler,这边因为我的两个链(电梯检验流程和起重机检验流程)是事先知道的,所以直接预先把每个handler的nexthandler设置好了。有的时候我们可能需要根据请求的具体参数(ProcessRequestDTO)里的不同属性值动态判断某个handler的nextHandler,那就可以在具体的Handler的重写的handle方法里根据参数决定set哪个handler为nextHandler。

0