6.2 开闭原则的庐山真面目
开闭原则的定义已经非常明确地告诉我们:软件实体
应该对扩展开放
,对修改关闭
,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化。
什么是软件实体
软件实体包括以下几个部分:
- 项目或软件产品中按照一定的逻辑规则划分的模块。
- 抽象和类。
- 方法。
开闭原则的要求
开闭原则告诉我们应尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来完成变化,它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。
注意开闭原则对扩展开放,对修改关闭,并不意味着不做任何修改,低层模块的变更,必然要有高层模块进行耦合,否则就是一个孤立无意义的代码片段。
变化分类
我们可以把变化归纳为以下三种类型:
1. 逻辑变化
只变化一个逻辑,而不涉及其他模块,比如原有的一个算法是a*b+c
,现在需要修改为a*b*c
,可以通过修改原有类中的方法
的方式来完成,前提条件是所有依赖或关联类都按照相同的逻辑处理。
2. 子模块变化
一个模块变化,会对其他的模块产生影响,特别是一个低层次的模块变化必然引起高层模块的变化
,因此在通过扩展完成变化时,高层次的模块修改是必然的。
3. 可见视图变化
可见视图是提供给客户使用的界面,如JSP
程序、Swing
界面等,该部分的变化一般会引起连锁反应。
- 如果仅仅是界面上按钮、文字的重新排布倒是简单,
- 最司空见惯的是业务耦合变化,什么意思呢?一个展示数据的列表,按照原有的需求是6列,突然有一天要增加1列,而且这一列要跨N张表,处理M个逻辑才能展现出来,这样的变化是比较恐怖的,但
还是可以通过扩展来完成变化
,这就要看我们原有的设计是否灵活。项目的基本过程
一个项目的基本过程应该是这样的:项目开发
、重构
、测试
、投产
、运维
。其中的 - 重构可以对原有的设计和代码进行修改,
- 运维尽量减少对原有代码的修改,保持历史代码的纯洁性,提高系统的稳定性。
原文链接: 6.2 开闭原则的庐山真面目