第一部分：设计模式六大原则解读——什么是开闭原则

设计模式六大原则解读——什么是开闭原则

author&＃xff1a;陈镇坤27

日期&＃xff1a;2022年2月8日

一、开闭原则

1、开闭原则的定义

Software entities like classes,modules and functions should be open for extension but closed for modifications

&＃xff08;软件应用中&＃xff0c;诸如类、模块和函数&＃xff0c;都应该对扩展开放&＃xff0c;对修改关闭。&＃xff09;

2、开闭原则的目的

应用需要发展&＃xff0c;便需要拥抱变化。设计类、模块、函数时&＃xff0c;便应该考虑到变化的可能&＃xff0c;以扩展的方式拥抱变化。

3、开闭原则示例

书店卖书&＃xff0c;关联接口IBook&＃xff0c;接口规定了书的几类方法&＃xff0c;其中实现类为NovelBook。

此时项目迭代&＃xff0c;要求对书进行打折处理。

方案一&＃xff1a;直接在IBook上新增方法getOffPrice

接口应该稳定且可靠&＃xff0c;直接在接口上进行修改&＃xff0c;会影响到所有的实现类&＃xff0c;接口本身也丧失契约功能。此外&＃xff0c;还将需要改变BookStore、NovelBook这几个类&＃xff08;新增方法getOffPrice的调用和实现&＃xff09;。

方案二&＃xff1a;直接修改实现类的getPrice方法

不行&＃xff0c;所有调用到该方法的其他类会受到影响。原本的含义被曲解。

方案三&＃xff1a;新增OffNovelBook子类继承NovelBook&＃xff0c;并对getPrice方法进行覆写。

可行&＃xff0c;UML如下所示&＃xff1a;

BookStore这个高层模块&＃xff0c;只需要对IBook这个表面类型的实际类型由NovelBook替换为OffNovelBook即可。

PS:业务的更迭&＃xff0c;有时候要求对必要的持久层操作进行替换&＃xff0c;这种改变在有时候是无可避免的&＃xff0c;我们应该做的是尽量减少这种改变。

4、如何在应用中遵循开闭原则&＃xff1f;

开闭原则的意义&＃xff1a;提高代码复用性、提高系统可维护性。

抽象约束&＃xff1a;

尽量以接口或抽象类来约束扩展&＃xff0c;并且需要做好边界限定&＃xff0c;遵循单一职责原则&＃xff08;实际开发同行很少遵循&＃xff09;。

参数类型或引用对象尽量使用接口或抽象类&＃xff08;实际开发我没遇到过&＃xff09;。

抽象层保持稳定&＃xff0c;确定即不可修改&＃xff08;实际开发我没遇到过&＃xff09;。

复制一段书中原话&＃xff1a;接口是与其他模块交流的契约&＃xff0c;修改契约就等于让其他模块修改。因此&＃xff0c;接口或抽象类一旦定义&＃xff0c;就应该立即执行&＃xff0c;不能有修改接口的思想&＃xff0c;除非是彻底的大返工&＃xff08;无法想象&＃xff09;

示例&＃xff1a;当书店要贩卖计算机书籍时&＃xff0c;UML图如下所示&＃xff1a;

良好的项目章程&＃xff1a;

统一的代码风格和规范&＃xff08;开发素质、项目节奏、公司章程缺一不可&＃xff09;

最重要的是&＃xff0c;预知变化&＃xff0c;预留空间。在最初便将设计做好。