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

背景

本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习《大话设计模式》时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅。

真诚的希望自己能够从一名小菜成长为一名大鸟!

编写的程序应该满足:

1)可维护

2)可扩展

3)可复用

4)够灵活

废话少说,言归正传,设计模式原则之:开放封闭原则

书面理解

开放封闭原则:软件实体(类、模块、函数等等)应该可以扩展,但是不可以修改

对于扩展是开放的,对于修改则是关闭的

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

实际开发过程中是很难通过猜测来判断哪些种类会发生变化的,但是我们却可以在发生小变化时,就及早想办法应对发生更大的变化的可能。也就是说,等到变化发生时立即采取行动。

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

面对需求,对程序的改动是通过增加新代码进行的,而不是更改现有的代码 。

我们希望的是在开发工作中展开不久就知道可发生的变化。查明可能发生变化所等待的时间越长,要创建正确的抽象就越困难。换句话说,如果在开发过程中已经使用或者依赖这个接口的地方越多,一旦这个接口需要继续变化时,继续抽象这个接口会越困难。

开发封闭原则是面向对象设计的核心之所在,遵循这个原则可以带来面向对象技术所声称的巨大好处。也就是可维护、可扩展、可复用,够灵活。

另外,开发人员应该仅对程序中呈现出频繁变化的那部分做出抽象,然而,对于应用程序中的每个部分都刻意地进行抽象同样是一个不好的主意。拒绝不成熟的抽象和抽象本身同样重要。

个人的理解

开放封闭原则是设计模式也是面向接口编程中最重要的一个原则,这种不能修改但可以扩展的思想是后期项目的维护与升级非常有利的基础。

如果你是做第三方SDK的API提供者,那么封闭开发原则显得尤为重要,试想,当你的程序无法满足客户需求,客户想要自定义程序的时候,如果你没有提供自定义扩展程序,那会是多么的尴尬。难道还要客户反编译你的代码进行重写吗?也许因为这个,或许客户会直接放弃使用这样的SDK,尤其现在开源SDK俯拾即是,一旦你的SDK不能对外扩张,那么路自然不会很长。

个人理解的开放封闭是:对外提供的接口,用户如果需要自定义功能(扩展)时,可以再不修改接口内部代码的基础上,通过新增代码模块来完成扩展的功能。所以面向接口编程以及面向对象的三大特征(继承、抽象、多条)显得尤为重要。

时间: 2024-10-10 06:23:03

小菜学设计模式——开放封闭原则的相关文章

设计模式——开放封闭原则

开放封闭原则:是说软件实体(类,模块,函数等等)应该可以扩展,但是不可修改. 这个原则有两个特征: 一个是对于扩展是开放的: 另一个是说对于更改是封闭的. 怎样的设计才能面对需求的改变却可以保持相对稳定,从而使得系统可以在第一个版本以后不断推出新的版本? 无论模块是多么的“封闭”,都会存在一些无法对之封闭的变化.既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择. 他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化. 面对需求,对程序的改动是通过增加新代码进

小菜学设计模式——依赖倒转原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:依赖倒转原则 书面理解 依赖倒转原则: A.高层次的模块不应该依赖于低层次的模块,他们都应该依赖于抽象. B.抽象不应该依赖于具体,具体应该依赖于抽象. 简单

小菜学设计模式——单一职责原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:单一职责 书面理解 单一职责:就一个类而言,应该仅有一个引起它变化的原因 如果一个类承担职责过多,接等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制

小菜学设计模式——合成复用原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:合成复用原则 书面理解 合成复用原则:要尽量使用合成/聚合,尽量不要使用继承. 对象的继承关系是在编译时就定义好了,所以无法在运行时改变从父类继承的实现.子类

小菜学设计模式——接口隔离原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:接口隔离原则 书面理解 接口隔离原则:使用多个小的专门的接口,而不要使用一个大的总接口. 接口应该是内聚的,应该避免"胖"接口.一个类对另

小菜学设计模式——迪米特原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:迪米特原则(最少知识原则) 书面理解 迪米特原则:如果两个类不必彼此直接通信,那么这两个类就应当发生直接的相互作用.如果其中一个类需要调用另一个类的某一个方法

小菜学设计模式——里氏替换原则

背景 本文标题为什么叫小菜学习设计模式,原因是本文内容主要是学习<大话设计模式>时的笔记摘要部分,当然,并不是记录书中小菜的学习过程,这个完全没有意义,而是指本人学习设计模式的成长之旅. 真诚的希望自己能够从一名小菜成长为一名大鸟! 编写的程序应该满足: 1)可维护 2)可扩展 3)可复用 4)够灵活 废话少说,言归正传,设计模式原则之:里氏替换原则 书面理解 里氏替换原则:一个软件实体如果使用的是父类的话,那么一定适用与其子类,而且它察觉不出父类对象和子类对象的区别.也就是说,在软件里面,把

大话设计模式---开放-封闭原则

对于扩展是开放的:对于更改是封闭的. 无论模块是多么的“封闭”,都会存在一些无法对之封闭的变化.既然不可能完全封闭,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择.他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化. 在我们最初编写代码时,假设变化不会发生.当变化发生时,我们就创建抽象来隔离以后发生的同类变化.

设计模式 之 设计的 六大原则(6) 开放封闭原则

  开放封闭原则  定义:一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来:在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案:当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化. 开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统.开闭原则可能是设计模式六项原则中定义最模糊的一个了,