第 4 章 开发—封闭原则

软件实体(类、模块、函数等等)应该可以扩展,但是不可修改。

 

对于扩展时开放的,对于更改时封闭的。

 

无论模块式多么的“封闭”,都会存在一些无法对之封闭的变化。既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出最有可能发生变化的种类,然后构造抽象来隔离那些变化。

 

在我们最初编写代码是,假设变化不会发生,当变化发生时,我们就创建抽象来隔离以后发生的同类变化。

面对需求,对程序的改动是通过增加新代码进行的,而不是更改现有的代码。这就是开发-封闭原则的精神所在。

 

开发-封闭原则是面向对象编程设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处,也就是可维护、可扩展、可复用、灵活性好。开发人员应该仅对程序中呈现频繁变化的那些部分做出抽象,然而,对于程序中灭个部分都可以的进行抽象同样不是一个好主意。拒绝不成熟的抽象和抽象本身一样重要。

 

 

 

时间: 2024-08-15 07:16:37

第 4 章 开发—封闭原则的相关文章

敏捷软件开发——开放—封闭原则(OCP)

由来: 怎么样的设计才能面对需求的改变却可以保持相对稳定,从而使得系统可以在第一版本以后不断推出新的版本呢?bertrand meyer 在1988年提出的著名的开发-封闭原则(the open-closed princle)为我们提供了指引. 遵循开放-封闭原则设计出的模块具有两个主要特征: 1. "对于扩张是开放的"(open for extension) 这以为着模块的行为是可以扩展的.当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的行为.也就是说,我们可以改变

开放封闭原则(OCP)

开放封闭原则 转:http://baike.baidu.com/view/2493421.htm转:http://dev.csdn.net/article/38/38826.shtm 开放封闭原则(OCP,Open Closed Principle)是所有面向对象原则的核心.软件设计本身所追求的目标就是封装变化.降低耦合,而开放封闭原则正是对这一目标的最直接体现.其他的设 计原则,很多时候是为实现这一目标服务的. 关于开发封闭原则,其核心的思想是: 软件实体应该是可扩展,而不可修改的.也就是说,

开放—封闭原则

案例:求职考研两不误.考研失败,工作没准备,这是不行的 开放——封闭原则:是说软件实体(类.模块.函数等等)应该可以扩展,但是不可修改. 两个特征:对应扩展是开放的,对于更改是封闭的. 怎么样的设计才能面对需求的改变却可以保持相对稳定,从而使得系统可以在第一个版本以后不断推出新的版本?:开放——封闭原则 案例:公司职员迟到:不可改变的是业绩成效,可改变的是上班的时间 无论模块是多么封闭,都会存在一些无法对之封闭的变化.既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪块变化封闭做出选择.必

小菜学设计模式——开放封闭原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:开放封闭原则 书面理解 开放封闭原则:软件实体(类.模块.函数等等)应该可以扩展,但是不可以修改 对于扩展是开放的,对于修改则是关闭的 无论模块是多么的封闭,

敏捷软件开发:原则、模式与实践——第9章 OCP:开放-封闭原则

第9章 OCP:开放-封闭原则 软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改. 9.1 OCP概述 遵循开放-封闭原则设计出的模块具有两个主要特征: (1)对于扩展是开放的(open for extension).这意味着模块的行为是可以扩展的.当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为. (2)对于修改是封闭的(closed for modification).对模块进行扩展时,不必改动模块的源代码或者二进制代码.模块的二进制可执行版本,无论是可链接

敏捷软件开发 – OCP 开放-封闭原则

软件实体(类.模块.函数等)应该是可以扩展的,但是不可修改的. 如果程序中的一处改动就会产生连锁反应,导致一系列相关模块的改动,那么设计就具有僵化性的臭味.OCP建议我们应该对系统进行重构,这样以后对系统再进行这样那样的改动时,就不会导致更多的修改.如果正确地应用OCP,那么以后再进行同样的改动时,就只需要添加新的代码,而不必改动已经正常运行的代码. OCP概述 遵循开放-封闭原则设计出的模块具有两个主要的特征.它们是: 对于扩展是开放的(open for extension).这意味着模块的行

敏捷软件开发:原则、模式与实践——第10章 LSP:Liskov替换原则

第10章 LSP:Liskov替换原则    Liskov替换原则:子类型(subtype)必须能够替换掉它们的基类型(base type). 10.1 违反LSP的情形 10.1.1 简单例子 对LSP的违反导致了OCP的违反: struct Point { double x, y;} public enum ShapeType { square, circle }; public class Shape { private ShapeType type; public Shape(Shape

敏捷软件开发:原则、模式与实践——第11章 DIP:依赖倒置原则

第11章 DIP:依赖倒置原则 DIP:依赖倒置原则: a.高层模块不应该依赖于低层模块.二者都应该依赖于抽象. b.抽象不应该依赖于细节.细节应该依赖于抽象. 11.1 层次化 下图展示了一个简单的层次化方案: 高层的Policy层使用了低层的Mechanism层,而Mechanism层又使用了更细节的Utility层.它存在一个隐伏的错误特征,那就是:Policy层对于其下一直到Utility层的改动都是敏感的.依赖关系是传递的. 下图展示了一个更为合适的模型: 每个较高层次都为它所需要的服

敏捷软件开发:原则、模式与实践——第5章 重构

第5章 重构 在Martin Fowler的名著<重构>一书中,他把重构定义为:“在不改变代码外在行为的前提下对对代码做出修改,以改进代码内部结构的过程.”可是我们为什么要改进已经能够工作的代码结构呢?我们不是都知道“如果它没有坏,就不要去修理它!”吗? 每一个软件模块都有3项职责.第一个职责是它运行起来所完成的功能.这也是该模块得以存在的原因.第二个职责是它要应对的变化.几乎所有的模块在它们的生命周期中都要变化,开发者有责任保证这种变化应尽可能地简单.一个难以改变的模块是有问题的,即使能够工