封装变化以实现去耦合

在《设计模式》一书中，使用最频繁的词可能就是“封装变化”和“去耦合”这两个了，这两个词的意义，其实不难理解，但是要在实际工程中恰当的应用，是非常困难的。
所谓封装变化，就是将可能发生变化的内容放到一起封装起来，对外只是提供固定的通讯方式。去耦合，顾名思义就是不同的内容的相互影响尽量小，一者发生改变时，另一者不需要随之改变。以下以实际项目中遇到的一些设计问题为例，对这两个词进行解读。
1. 在多处可能都需要作同一件事情，而这一件事情虽然现在很简单，但是未来可能需要扩展，这时候考虑用函数来封装之，显然这是一个封装变化的实例。去耦合体现在那里呢？原来分散在各处的相同的代码都到了一个函数中，当有改变需要发生时，只需要函数改变即可，而不用每一处都更改，这是一种松散耦合，而原来的设计是强耦合的。
2. 类的实现继承也可能引入强耦合。派生类的实现要依赖于基类的实现，而基类又通过虚函数调用派生类的代码，于是对于复杂的类，调用关系变得非常复杂。在很多情况下，我们不能轻易改变基类的实现，因为基类的实现改变，有可能导致派生类代码也需要更改。这主要源于实现继承，派生类可以看到基类的实现，而基类的内部实现必然是强耦合的，派生类可以看到这种强耦合的实现，就不可避免的依赖于这种强耦合，因而带来了派生类与基类之间的强耦合，并且逐步延伸开来引入与其他类的强耦合，最终使得整个系统的各个部分之间的强耦合关系。而接口继承则可以避免这一点，一个类从一个接口继承，它仅仅能看到接口规范，只要接口规范满足，内部如何实现其它类并不关心。这样可以达到不同的对象仅仅通过接口发生耦合。
3.实现继承的好处是可以少写代码，但是却带来扩展性的变差。而接口继承，代码的重用就少多了，它能够重用的最小单元是接口。接口实现即使稍有不同，所有的接口都必须重写。但是接口继承带来了可扩展性和兼容性的提高，尤其是大型的系统开发效果更加明显。而且，接口继承本身就反映了一种封装变化的思想：将相关的内容封装到接口中，内部实现则是可以任意变化的，所以我们可以看到不同的接口之间没有相互约束，每一个接口的实现代码和流程都是非常清晰的。现在的问题在于：哪些是需要封装的，应该封装到哪一个接口里去，接口之间的关系，系统如何使用这些接口。这些问题都是和具体项目相关的，必须结合项目具体问题具体分析，但是最终的目的还是为了实现去耦合。

待续。。。