概要
OCP原则
一个软件实体如类、模块和函数应该对扩展开放,对修改关闭。
Softeware entities like classes,modules and functions should be open for extension but closed for modifications.
开闭原则的含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有代码来实现变化。
软件实体包括以下几个部分:
- 项目或软件产品中按照一定的逻辑规则划分的模块
- 抽象和类
- 方法
开闭原则是为软件实体的未来事物而制定的对现行开发设计进行约束的一个原则。
注意:开闭原则对扩展开放,对修改关闭,并不意味着不做任何修改,低层模块的变更,必然要有高层模块进行耦合,否则就是一个孤立无意义的代码片段了。
变化的类型:
- 逻辑变化
- 子模块变化
- 可见试图变化
一个项目的基本路径应该是这样的:项目开发、重构、测试、投产、运维,其中的重构可以对原有的设计和代码进行修改,运维尽量减少对原有代码修改,保持历史代码的纯洁性,提高系统的稳定性。
开闭原则的重要性:
- 开闭原则对测试的影响
开闭原则可是保持原有的测试代码仍然能够正常运行,我们只需要对扩展的代码进行测试就可以了。
- 开闭原则可以提高复用性
在面向对象的设计中,所有的逻辑都是从原子逻辑组合而来的,而不是在一个类中独立实现一个业务逻辑。只有这样代码才可以复用,粒度越小,被复用的可能性就越大。
- 开闭原则可以提高可维护性
- 面向对象开发的要求
提出问题
需求:有一个电子销售系统需要打印顾客所购买的商品的发票(Invoice),一张发票可以分成三个部分:
Ø 发票头部(Header):上面有顾客的名字,销售的日期。
Ø 发票主部:销售的货物清单,包括商品的名字(Item)、购买的数量(Units)、单价(Unit Price)、小计(Sub Total);
Ø 发票的尾部(Footer):商品的总金额(Total);
下面是打印出的发票的大致的样子:
********************** INVOICE ************************************
XYZIncorporated
Date of Sale: Sun May 26 21:42:36 EDT 2002
Item Units Unite Price Subtotal
FireWheel Tire 4 $154.3 $616.92
FrontFender 1 $300.45 $300.45
Total $917.37
需要提醒的是:
Ø 发票的头部和尾部可以有很多种可能的格式,因此系统的设计必须给出足够的灵活性,使得一个新的头部和新的尾部格式能够比较容易地插入到系统中;
Ø 同时,本系统的客户端必须可以随意地选择某一个头部格式和某一个尾部格式的组合并与主部格式结合起来。
问题分析
类图
{
getInvoice().print;
System.out.println("这个类所要打印的内容");
}
这样我们就可以实现递归,也就是先调用传进来的Invoice类型的对象的print方法再打印自己的打印内容