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

    背景

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

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

    编写的程序应该满足：

    1）可维护

    2）可扩展

    3）可复用

    4）够灵活

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

    书面理解

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

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

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

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

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

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

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

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

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

    个人的理解

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

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

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