“融化奶酪效应”的处理

核心提示： 所以不管是使用动态链接库还是服务（我们已经解释过面临的问题都是一样的），与底层实现的绑定才是问题的关键所在，“融化奶酪效应”的处理(10)，我们坚信这个问题的解决方案存在于合理定义的合同结构以及使用所谓的“合同优先设计方法”，为了避免对工程造成的影响，在用户方，你们

所以不管是使用动态链接库还是服务（我们已经解释过面临的问题都是一样的），与底层实现的绑定才是问题的关键所在。我们坚信这个问题的解决方案存在于合理定义的合同结构以及使用所谓的“合同优先设计方法”。

为了避免对工程造成的影响，我们必须在设计的不同阶段采取以下方法：

用户需要：

• 与合同进行绑定

• 使用配置（制造厂）获得终端访问入口

服务方需要：

• 为重大改动提供新的合同和终端，最好是在保留原有合同和终端的基础上

• 在不影响合同和终端的基础上完成对底层实现的替换更新

将服务方视为一个黑盒子：

• 服务方为每一个合同提供了一个终端。进行一个与以往合同不兼容的改变需要增加一个新的终端，也就是提供一个新合同的访问入口，此时，最好保留旧的终端。

• 客户绑定到一个终端上

但是，用户与某一终端的绑定并不需要代码编写，更好的方式是使用配置。这使得我们可以移动终端甚至对使用某一特定终端的用户进行搜索。

再来看一下服务本身，当我们想置换外部合同的时候，可以找到想要替换的组件：

• 一个组件提供了多个接口和合同。当提供一项新的功能时，我们并不总是想提供额外的接口。也许我们更愿意提供一个新的组件版本，在添加一些新的、改进过的接口的同时保留原有的接口。

• 一个用户使用这个组建需要与相应的合同进行绑定，也就是与组件接口的集合以及被其使用的数据类进行绑定。

• 用户不需要与接口和底层实现同时绑定。他可以使用代码方式与接口绑定—即在代码中引用接口，或者使用配置的方式与底层实现进行绑定。可能需要一个对象制造厂来实现与底层解除绑定。

当一项服务或者其中的一个服务组件发生了改变后，使用原有接口的用户不一定非要跟着变。只有那些被改进功能影响到的用户需要改变和重新编译。这样可以减少依赖性，减少对重编译的需要，更重要的是，可以减少需要重新投入使用的组件数量。

这个建议无疑会导致接口数量的增加。这在过去是一个编写代码时遇到的问题，但是现在，它已经变成了管理激增的接口的问题了。我倒不认为这是一件坏事，相反，也许正是我们所需要的。但是，我们也要为这个问题做好准备（在这方面进行专门研究的公司有Systinet和Actional）

结论

对于一个由松耦合服务搭建起来的系统来说，合同以及它们的设计无疑是至关重要的。在下一篇文章中我会返回来继续讨论合同的问题，但是，就像我们在动态链接库灾难例子中看到的那样，对于如何在服务中提供合同以及如何在客户端使用合同需要非常的小心。在服务方，我们必须考虑如何提供多个版本的合同。

在用户方，你们必须确保是绑定到一个合同上而并非一个底层实现上，制造厂在这个问题上提供了一个很好的机制。