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

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

这个原则其实有两个特征, 对于扩展是开放的, 对于更改是封闭的.

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

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

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

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

扫描二维码关注公众号,回复: 1161968 查看本文章

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

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

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

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

应对变化的时间点:

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

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

猜你喜欢

转载自www.cnblogs.com/ITPower/p/9112243.html
今日推荐