“融化奶酪效应”的处理

　　这是Web Service设计方法系列文章中的第一篇，这个系列的文章重点介绍如何能够设计出在未来业务中拥有灵活应变能力的Web Service。

　　介绍

　　这些想法集思广益的结果，首先是Beat Schweqler以及我们在去年在阿姆斯特丹举行的TechEd上做的名为“使用面向对象技术实现服务的灰色地带”的演讲；以及Michael Regan，他对大量的使用者做过实地调查；最后是Christian Weyer，thinktecture的奠基人之一，他最近提出了一个新的工具环境叫做网络服务合同优先(Web Service Contract First, orWSCF)。我们大家的不同之处仅仅是Christian更多的关注那些懂得结构的受众，但是我们最初的努力是针对那些避开了结构的受众（点击这里浏览Christian的blog）。

　　导航

　　在接下来的这些文章中，我们将会引领您从高层次的抽象思考逐步具体化，最后给出切实可行的建议。同时，我们还将提供一个工具集来支持我们的建议，帮助您建立，提供并使用合同。我们希望这些工具可以从未WSCF的一部分或者变成一个全新的工具集。

　　• 第二篇文章—合同将会提供给您一个关于对话、合同以及约定的观点。我将发表我关于合同、代码编写、结构优先讨论上的一些个人观点。

　　• 在第三篇文章中，我将深入地探讨如何构建一个解决方案，展示一些在重用结构时您可能预想不到的问题并给出初步的建议

　　• 在第四篇文章中，我将展示一个工程的方案并设计一个可以灵活应变的服务结构。

　　• 在这个系列的第五篇文章中，将会展示前面那个工程的配套工程，并为其客户端设计结构

　　至于后面的文章，我们还没有太明确的计划到地写些什么。其内容应该会取决于我们在提供工具上的进度以及读者给我们的反馈。

　　范围

　　我们不想把焦点仅局限于互联网范畴内的交互服务，在那里各种组织会根据各自的需要对合同进行随意的改动。我们接触到的大多数人，媒体和大型机构组织都希望了解如何才能制定出适合自身的，可以与时俱进的解决方案。在很多情况下，设计服务的机构都会拥有两个终端，它们至少会对这两方—服务使用者和服务提供者产生影响。我们希望可以帮助这些组织里的工程师和设计者们应付并尽量减少对其设计进行的改动时的复杂度。

　　在这个系列文章中，我们探讨了如何在一个面向服务的环境中对一个复杂系统进行变更的问题，并会就如何在媒体和大型组织中设计并构建服务给出指导。我们并非要试图为世界范围内的各种消费需要解决设计结构和协议的复杂性问题。这个系列文章并非什么万灵丹，但是它可以向您提供一些有用的指导，帮助您设计出更加灵活应变的解决方案。我们将从一个高层次的角度来审视这个问题，然后逐层深入，给出具体的结构和代码。为了配合这个系列文章，我们还发布了一些工具软件来支持我们的建议，我们希望这些工具可以融入到WSCF中。

　　融化的奶酪

　　不久前，我们摒弃了声名狼藉的意大利拉面式的过程化编程方式，从GOTO指令泛滥的“跳转纪元”进入了面向对象的世界，我称之为小方饺式的编程方式。这种编程方式的一大优点就是你对模块内部的改动不会对它的外部造成影响，就像隔着饺子皮看不出馅被换过一样。但是，一旦某个模块的功能发生了变化，它还是会影响到其他模块的，因为它们之间确实是存在联系的，这种关系就像煮在同一锅汤里的一个个饺子一样，汤汁把它们联系在了一起—我正是从这种汤汁联想到了融化的奶酪的这个形象。

　　动态链接库灾难就是一个反应这种融化奶酪效应的好例子。通常，多重应用会依赖于同一个动态链接库，只要其中的一个应用被更新，这个动态链接库就需要被相应地改动以适应这个应用的新版本，随着而来的是其他所有依赖于这个动态链接库的应用都需要进行改动。

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

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

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

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

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

　　在几年以前的一项工程中，一位市场部经理对一款办公室管理产品进行介绍，他称赞了它的功能并提到它与同类产品比起来是多么的出色。继而又对我们取得的进步表示了肯定。就当我们在如此盛赞之下开始沾沾自喜起来的时候，他提出产品有一个小问题，那就是它无法进行打印。

　　在今天，这种问题的出现是不可想象的。打印机的驱动在整个工业界都执行相同的标准。可能每个驱动都会具有一些自身的特点，但是本质上，进行打印这个应用已经不需要了解一个打