“融化奶酪效应”的处理

核心提示： • 我可以允许使用者有自己的更新日程并保证关键的业务功能不会因为更新进度不同而受到影响吗？当你想改变一项服务的功能时，你不得不让它的消费方，“融化奶酪效应”的处理(9)，客户方和其他互动服务也相应的进行改变，你可能处在一个比较幸运的环境中，统一标识符（终端）通常是和底层实现联系在

• 我可以允许使用者有自己的更新日程并保证关键的业务功能不会因为更新进度不同而受到影响吗？

当你想改变一项服务的功能时，你不得不让它的消费方，客户方和其他互动服务也相应的进行改变。你可能处在一个比较幸运的环境中，可以同时实现服务方和用户方的改变，但是，由于各种各样的原因，这并不总是可能的，比如说：

• 你不能影响所有消费者（也就是说你可能可以改变一些消费者，但你无法改变所有消费者）。

• 你没有时间让所有的消费者/客户为变化最好准备，你只能先让一部分人使用变更后的版本。

• 你并不想把新功能一次性的展示给所有的用户，你想先在一部分用户中试行一段时间。

• 你不得不一点一点地进行变动，这可以由很多原因造成。

在上述所有情况中，新一批用户与先前的用户必须同时使用旧的服务版本。虽然可能不太常见，但相反的情况也是有可能发生的，那就是一个用户需要同时与多个版本的服务进行交互，比如说当从各种子服务中整合信息的时候。

版本更新的一个主要目标就是从一个稳定的情况顺利过渡到另一个稳定的情况。了解版本更新可能对合同造成的影响可以使我们区分哪些部分是可以共同工作的，哪些是不能的。

合同

我并不认为使用者同时依赖于动态链接库的接口和它的底层实现是造成动态链接库灾难的一个原因。组件技术提供给我们一个明确的接口和底层实现的划分，使得使用者只依赖接口，而不依赖于底层实现。但是使用它的程序员利用底层实现可以更轻松的实例化一个对象而无需借助于对象制造厂。对于服务方（编写组件）的程序员，可能更愿意选择利用相同的统一标识符(GUID)轻松地实现一个并不兼容的改动。在组件技术中，统一标识符（终端）通常是和底层实现联系在一起的。较少有开发者会为单独的类提供出各种额外的接口，以备将来可以不必破坏原有应用就进行更新。