“融化奶酪效应”的处理

核心提示： 面对那些前所未有的复杂系统，我们在如何对它进行改变的问题上有些束手无策，“融化奶酪效应”的处理(3)，像动态链接库灾难这样的问题只是小巫见大巫，我们可以实现对系统的某个部分的改变，否则它将把你限制在一个单独的层次结构和使用中，组件技术和后来的JAVA和C#（或者更好的；比如CLR）将接口的

面对那些前所未有的复杂系统，我们在如何对它进行改变的问题上有些束手无策，像动态链接库灾难这样的问题只是小巫见大巫。我们可以实现对系统的某个部分的改变，但却不知道如何协调各个部分之间的相互关系。这些不同的部分的更新换代速率不同，在不同系统上的应用次数也各异。其他系统的情况也好不到哪里去，而且它们不断地提出越来越复杂的需求。

下面，我们来深入地分析一下造成融化奶酪效应的一个原因。

当使用一个类的时候，我们会声明一个名字来引用这个类的一个实例。我们清楚地知道这个类有哪些方法、域、属性、行为和数据。但是，我们不能简单的用另外一个类来替换掉这个类，因为我们还必须对所有对这个类进行过引用的代码进行改变。即使在不改变类的方法、域、属性的名字的前提下，也不能轻而易举的实现对类的改变，因为还要进行重新编译。

如果对这些问题置之不理的话，面向对象的编程方法的影响在我们试图对一个类进行修改的时候就会暴露出来。我们不得不同时改变很多类的实现，或者至少需要重新编译一下，以确保这些对象之间可以正确的链接起来。当很多不同组件中的类的都对另外一个组件中的类进行了引用的时候，情况有可能变得更糟，因为如果删除那个被引用的类，真正需要担心的不再是一个组件中有多少个类需要重新编译，而是有多少个组件需要重新编译。

在早期的面向对象编程中，通常使用继承和抽象类来减少类之间的依赖性。虽然这些方法也起到了一定程度的作用，但是继承并不是依赖性问题的最佳解决方法。使用继承主要解决的是实现的重用问题。继承不仅将类的内部结构暴露了出来，而且除非你使用的是多继承，否则它将把你限制在一个单独的层次结构和使用中。组件技术和后来的JAVA和C#（或者更好的；比如CLR）将接口的概念引入到了主流编程思想中。接口为使用提供了一个更加灵活的绑定机制。