“融化奶酪效应”的处理

核心提示： 在几年以前的一项工程中，一位市场部经理对一款办公室管理产品进行介绍，“融化奶酪效应”的处理(4)，他称赞了它的功能并提到它与同类产品比起来是多么的出色，继而又对我们取得的进步表示了肯定，只要有一个服务的行为模式发生改变，其他的服务和客户也都需要进行改变，就当我们在如此盛赞之下开始沾沾自喜起

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

在今天，这种问题的出现是不可想象的。打印机的驱动在整个工业界都执行相同的标准。可能每个驱动都会具有一些自身的特点，但是本质上，进行打印这个应用已经不需要了解一个打印机的细节。众多的打印机驱动程序并没有一个共同的基类。这有助于减少编程量，但是对实现标准化却作用不大。它们都提供了统一的对外接口—一个统一的方法和消息集，通过这些可以对打印机进行访问。打印机使用者与打印机之间是一种松散连接的关系，与打印机驱动之间也没有直接绑定，而是使用了一个对象制造厂，它会要求操作系统给出正确驱动程序的地址入口，或者直接遍历系统找到正确的驱动。

接口和制造厂的结合使用有助于实现这种松散连接并且缓解了融化奶酪效应。

面向服务真的可以把奶酪彻底分开吗？

凭借优势，面向服务概念正在广泛被接受。面向服务的结构和设计试图利用语句来定义一些黑盒子，使得对任何服务的改变都不会影响到其他的服务，因此也就避免了动态链接库灾难这样的问题。这个思想在理论上是成立的，但是具体到实践上，如何在这一个个黑盒子之间进行通信需要一点点技巧。来自不同经销商的系统，使用各种不同的技术彼此进行交流，工业界一直努力简化这些技术。特别是现在为了解决这个问题，服务的思想，更确切的说是Web Service的思想正在逐渐强大起来。

但是，有一件事情我们可能忘记了，或者至少是没有足够重视，那就是如何对一个方案进行局部改变问题。很多工具都可以帮助组织，部门甚至个人轻松地建构和使用一个服务。通常，这些服务都是用来进行不同终端之间的协同工作的。但是，很少有工具是可以用来进行将来有可能的变更的，即使有工具，相关的指导，实例和支持标准也都是很缺乏的。当我们从面向对象和动态链接库灾难中走出，前进到面向服务时，这个问题并没有什么本质上的变化。面向服务带给了我们更加复杂和庞大系统，而我们关注的焦点也必须随之改变。新的服务需要被开发，现行的服务需要被改变，所有的服务的用途都可能超过设计者的设计意图。只要有一个服务的行为模式发生改变，其他的服务和客户也都需要进行改变。他们之间的联结方式已远非当初设计的那样了。