OOD设计原则之OCP、LSP

一直谈软件设计，却不能准确的描述。结合最近看《黑客与画家》，这才对设计的六大原则有了一点浅显的体会。首先说一下一个项目的路径：开发、重构、测试、投产、运维。其中重构的好处就是希望对原有设计和代码进行修改（注意：重构的应该分两个方向：设计上的修改和代码上的修改），而运维则是希望尽量减少对原有代码的修改，保持历史代码的纯净，提高系统稳定性。

原则一：开闭原则（OCP）

 软件应该保持对扩展开放，对修改关闭。开发的时候要允许在已有软件模块的基础上进行拓展功能，并尽可能不去修改已有的功能模块。换句话说就是一个软件实体应该通过扩展来实现变化，而不是通过修改已有代码来实现变化。

那么如何使用这个原则呢？个人认为核心是找到或者预见未来可能发生变化代码块。在具体使用的时候可以考虑：

1、通过使用接口或者抽象类约束扩展，并对扩展的边界进行限定，保证出现在接口或抽象类中方法都是有用的方法。

2、参数类型尽可能是接口或者抽象类，而不是某一个实现类。

3、合理的设计抽象类和接口，也就是尽可能的保持抽象层的稳定，一经确定不允许修改。

4、尽可能的通过元数据来控制模块的行为。简单点说通过配置参数，来控制模块的模块的功能。参数既可以写在普通文件中，也可以保存在数据库中。提到这一点就不得不说Spring容器，Spring就是一个典型的通过元数据来控制模块行为。仅仅通过元数据控制模块是不够的，用到极致的是IOC，也就是控制反转。

5、统一项目约束，团队中的所有人员必须遵守项目约束，比如说命名规则等。（团队合作中非常重要）

6、封装变化，将相同的变化封装到同一个接口或者抽象类中，不同