| 订阅 | 在线投稿
分享
 
 
 

一些面向对象的设计法则(3)

来源:互联网  宽屏版  评论
2008-05-31 11:18:25

法则3:开放-封闭法则(OCP)

软件组成实体应该是可扩展的,但是不可修改的。

[ Software Entities Should Be Open For Extension, Yet Closed For Modification

]

开放-封闭法则

1.开放-封闭法则认为我们应该试图去设计出永远也不需要改变的模块。

2我们可以添加新代码来扩展系统的行为。我们不能对已有的代码进行修改。

3.符合OCP的模块需满足两个标准:

4.可扩展,即"对扩展是开放的"(Open For Extension)-模块的行为可以被扩展,以需要满足新的需求。

5.不可更改,即"对更改是封闭的"(Closed for Modification)-模块的源代码是不答应进行改动的。

6.我们能如何去做呢?

a.抽象(Abstraction)

b.多态(Polymorphism)

c.继续(Inheritance)

d.接口(Interface)

7. 一个软件系统的所有模块不可能都满足OCP,但是我们应该努力最小化这些不满足OCP的模块数量。

8.开放-封闭法则是OO设计的真正核心。

9.符合该法则便意味着最高等级的复用性(reusability)和可维护性(maintainability)。

OCP示例

1. 考虑下面某类的方法:

一些面向对象的设计法则(3)

2.以上函数的工作是在制订的部件数组中计算各个部件价格的总和。

3.若Part是一个基类或接口且使用了多态,则该类可很轻易地来适应新类型的部件,而不必对其进行修改。

4.其将符合OCP

5. 但是在计算总价格时,若财务部颁布主板和内存应使用额外费用,则将如何去做。

6.下列的代码是如何来做的呢?

一些面向对象的设计法则(3)

7.这符合OCP吗?

8.当每次财务部提出新的计价策略,我们都不得不要修改totalPRice()方法!这并非"对更改是封闭的"。显然,策略的变更便意味着我们不得不要在一些地方修改代码的,因此我们该如何去做呢?

9.为了使用我们第一个版本的totalPrice(),我们可以将计价策略合并到Part的getPrice()方法中。

10.这里是Part和ConcretePart类的示例:

一些面向对象的设计法则(3)

11. 但是现在每当计价策略发生改变,我们就必须修改Part的每个子类!

12.一个更好的思路是采用一个PricePolicy类,通过对其进行继续以提供不同的计价策略:

一些面向对象的设计法则(3)

一些面向对象的设计法则(3)

13.看起来我们所做的就是将问题推迟到另一个类中。但是使用该解决方案,我们可通过改变Part对象,在运行期间动态地来设定计价的策略。

14.另一个解决方案是使每个ConcretePart从数据库或属性文件中获取其当前的价格。

单选法则

单选法则(the Single Choice Principle)是OCP的一个推论。

无论在什么时候,一个软件系统必须支持一组备选项,理想情况下,在系统中只能有一个类能够知道整个的备选项集合。

  法则3:开放-封闭法则(OCP)      软件组成实体应该是可扩展的,但是不可修改的。      [ Software Entities Should Be Open For Extension, Yet Closed For Modification   ]                           开放-封闭法则                     1.开放-封闭法则认为我们应该试图去设计出永远也不需要改变的模块。      2我们可以添加新代码来扩展系统的行为。我们不能对已有的代码进行修改。      3.符合OCP的模块需满足两个标准:      4.可扩展,即"对扩展是开放的"(Open For Extension)-模块的行为可以被扩展,以需要满足新的需求。      5.不可更改,即"对更改是封闭的"(Closed for Modification)-模块的源代码是不答应进行改动的。      6.我们能如何去做呢?      a.抽象(Abstraction)      b.多态(Polymorphism)      c.继续(Inheritance)      d.接口(Interface)            7. 一个软件系统的所有模块不可能都满足OCP,但是我们应该努力最小化这些不满足OCP的模块数量。      8.开放-封闭法则是OO设计的真正核心。      9.符合该法则便意味着最高等级的复用性(reusability)和可维护性(maintainability)。      OCP示例         1. 考虑下面某类的方法:       [url=http://www.wangchao.net.cn/bbsdetail_1758846.html][img]http://image.wangchao.net.cn/it/1323510358625.gif[/img][/url]      2.以上函数的工作是在制订的部件数组中计算各个部件价格的总和。      3.若Part是一个基类或接口且使用了多态,则该类可很轻易地来适应新类型的部件,而不必对其进行修改。      4.其将符合OCP            5. 但是在计算总价格时,若财务部颁布主板和内存应使用额外费用,则将如何去做。      6.下列的代码是如何来做的呢?       [url=http://www.wangchao.net.cn/bbsdetail_1758846.html][img]http://image.wangchao.net.cn/it/1323510358694.gif[/img][/url]   7.这符合OCP吗?      8.当每次财务部提出新的计价策略,我们都不得不要修改totalPRice()方法!这并非"对更改是封闭的"。显然,策略的变更便意味着我们不得不要在一些地方修改代码的,因此我们该如何去做呢?      9.为了使用我们第一个版本的totalPrice(),我们可以将计价策略合并到Part的getPrice()方法中。            10.这里是Part和ConcretePart类的示例:       [url=http://www.wangchao.net.cn/bbsdetail_1758846.html][img]http://image.wangchao.net.cn/it/1323510358731.gif[/img][/url]      11. 但是现在每当计价策略发生改变,我们就必须修改Part的每个子类!      12.一个更好的思路是采用一个PricePolicy类,通过对其进行继续以提供不同的计价策略:       [url=http://www.wangchao.net.cn/bbsdetail_1758846.html][img]http://image.wangchao.net.cn/it/1323510358810.gif[/img][/url]      [url=http://www.wangchao.net.cn/bbsdetail_1758846.html][img]http://image.wangchao.net.cn/it/1323510358869.gif[/img][/url]   13.看起来我们所做的就是将问题推迟到另一个类中。但是使用该解决方案,我们可通过改变Part对象,在运行期间动态地来设定计价的策略。      14.另一个解决方案是使每个ConcretePart从数据库或属性文件中获取其当前的价格。                                 单选法则                     单选法则(the Single Choice Principle)是OCP的一个推论。      无论在什么时候,一个软件系统必须支持一组备选项,理想情况下,在系统中只能有一个类能够知道整个的备选项集合。
󰈣󰈤
 
 
 
>>返回首页<<
 
 热帖排行
 
 
 
静静地坐在废墟上,四周的荒凉一望无际,忽然觉得,凄凉也很美
©2005- 王朝网络 版权所有