开放-封闭原则(OCP)

对于僵化性的臭味,应用OCP原则之后,再进行同样的改动时,只需添加新代码,而不必改动已正常运行的代码.
1. 扩展模块行为的方式通常是修改模块的Code,不允许修改的模块常常被认为是具有固定的行为.
2. Open:模块的行为是可以扩展的,即可以改变模块的功能.
3. Close:对模块进行扩展时,不必改动DLL,Code,lib等.
4. 封闭创建于抽象的基础之上.
关键是抽象.
1. 抽象基类: 固定,能够描述一组任意个可能行为的抽象体.
2. 派生类: 一组任意个可能的行为的表现.
3. 模块操作抽象体.所以模块的依赖是一个固定(对修改封闭的)的抽象体.然后,通过从这个抽象体派生,可以扩展此模块的行为.
1. 该结构的问题:
  1. 很可能会需要在switch中进行if/else判断.导致理解和发现所有需要增加对新增类型进行判断的难度.
  2. 同时,在给Type枚举添加成员时,由于所有的子类都依赖于该枚举,所以必须编译所有子类DLL.
3. 再新增新类型时,只需要派生一个具有新功能的子类,并且实现相应的方法.同时更改main之类的new子类的地方.
4. 而不再需要再改动系统既存的任何代码.
预测变化和"贴切的"结构.
1. 如果预测到了某种变化,那么就可以设计一个抽象来隔离它.
2. 无论模块多么的封闭,都存在以下无法对之封闭的变化.即没有对所有情况都贴切的模型.
3. 所以,我们从经验中预测最有可能发生的变化的种类,然后构造抽象来隔离那些变化.
4. 遵循OCP原则的代价很大,并且抽象本身也会增加设计的复杂性.开发人员也只能处理有限数量的抽象.
防止Hook.
1. hook本身需要支持和维护,当不使用它们时就具有了不必要的复杂性的臭味.
2. 只受一次愚弄.最初我们编写代码时,假设变化不会发生.当变化真的发生时,我们创建抽象来隔离以后发生的同类变化.
3. 刺激变化,来尽早地查明可能发生的变化.

总结. 我们通过抽象来实现封闭,通过重载/hook来实现扩展.

只有当我们预测到了某种变化发生的可能性,或者某种变化已经发生时,才会创建抽象来应对以后同类的变化.

抽象会带来复杂性和成本.拒绝不成熟的抽象,和抽象本身一样重要.

[Agile Software Development(Principles,Patterns,and Pracitices)]