标签：原则 -- 大话 封闭 发生 抽象 设计 设计模式 变化

开放--封闭原则：

 

一、概念

开放-封闭原则, 指的是软件实体（类， 模块， 函数等等）应该可以扩展， 但是不可修改。

这个原则其实有两个特征, 对于扩展是开放的, 对于更改是封闭的. 做法: 对变化点进行抽象

 

我们在做任何系统的时候, 都不要指望系统一开始时需求确定, 就再也不会变化, 这是不现实也是不科学的. 那么如何在面对需求的变化时, 设计的软件可以相对容易修改。不至于说， 新需求一来， 就把整个程序推翻重来。怎么样的设计才能面对需求的改变时， 可以保持相对稳定， 从而使得系统可以在第一个版本以后不断推出新的版本呢？ 答案是： 开放-封闭原则。

 

第一点:尽可能的将类设计的足够好 

开放--封闭原则意思是说: 你设计的时候, 时刻要考虑, 尽量让这个类足够好。写好了，就不要去修改了，如果新需求来了， 我们增加一些类就完事了， 原来的代码能不动则不动。

 

第二点: 提前预测变化点, 对变化点进行抽象隔离 

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

 

但是, 猜测程序可能发生的变化的话, 猜对了, 那是成功, 猜错了, 那就完全走到另一面去了, 把本该简单的设计, 做的非常的复杂. 这很不划算呀. 而且,事先猜测, 这是很难做到的. 

 

那么, 我们应该如何做呢?

我们很难预先猜测, 但我们却可以在发生小变化时, 就要及早想办法应对发生更大变化的可能。也就是说， 等到变化发生了， 立即采取行动。 正所谓， 同一个地方摔倒一次可以， 如果再次摔倒， 那就是自己的不对了。

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

 

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

 

应对变化的时间点:

我们要尽可能在开发工作展开不久就知道可能发生的变化，查明可能发生的变化所等待的时间越长， 要创建正确的抽象就越困难。

 

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

 

标签：原则,--,大话,封闭,发生,抽象,设计,设计模式,变化
来源： https://blog.51cto.com/u_15091061/2858233

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。