开放封闭原则是说软件实体（类、模块、函数等等）应该可以扩展，但是不可以修改【ASD】。
这原则有两个特征，对于更改是封闭的，对于扩展是开放的。我们在做任何系统的时候都不要指望一开始需求就确定，就再也不会变化，这时不现实的。面对需求的改动，怎样保持系统的相对稳定，从而使系统可以在第一个版本之后不断推出新的版本呢？开放封闭原则给了我们答案。设计软件要容易维护又不容易出问题的最好办法就是多扩展，少修改。绝对的对修改关闭是不可能的，无论模块有多么“封闭”，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对他设计的模块应该对哪种变化封闭做出选择。他必须先猜测出可能发生的变化种类，然后构造抽象来隔离那些变化。我们很难预先猜测，但我们可以在发生小变化时，就及早想办法应对发生更大变化的可能，也就是说发生变化时立即采取行动。
我们在最初编写代码时，假设变化不会发生。当变化发生时，我们就创建抽象来隔离以后发生的同类变化。比如我们之前写的加法程序，我们在一个client类中就可以很快完成，此时变化还没有发生。然后我们加一个减法功能，发现增加功能需要修改原来的这个类，这就违背了“开放封闭原则”。于是就要考虑重构程序，增加一个抽象的运算类，通过面向对象的一些手段，如继承、多态来隔离具体加法、减法与client的耦合。需求仍然能够满足，还能应对变化。即面对需求，对程序的改动是通过新增代码进行的，而不是更改现有的代码。这就是“开放封闭原则”的精神所在。
当然并不是什么时候应对变化都是容易的。我们希望在开发工作展开不久就知道可能发生的变化，查明可能发生的变化所等待的时间越长，要创建正确的抽象就越困难。
“开放封闭原则”是面向对象设计的核心所在。遵循这个原则可以带来面向对象技术所声称的巨大好处，也就是可维护，可扩展，可复用，灵活性好。开发人员应该仅对程序中呈现出频繁变化的那些部分作出抽象，然而，对应用程序中的每个部分都刻意地进行抽象同样不是一个好主意，拒绝不成熟的抽象和抽象本身一样重要。
如对本文有疑问， 点击进行留言回复！！
软件设计模式六大原则-接口隔离原则 Interface Segregation Principle
设计模式之解释器模式（附：SpelExpressionParser中解释器模式应用分析）
我要评论
网友评论