分布式软件设计之DECORATOR模式（三）

                       分布式软件设计之DECORATOR模式

   自从上次写了两篇文章 分布式软件设计之DECORATOR模式（一）、（二）。在前两篇文章举的例子还不能充分说明利用这个模式的有点。

   不过之所以把这个方法叫DECORATOR模式，可能是因为这个方法就是在不修改当前的软件设计，而是仅仅加了一些职责。这样的方法姑且套用设计模式的DECORATOR模式。

    这个方式之所以可行，因为基于TCP/IP的分布式软件设计的功能基于彼此之间的协议交换。

  比如如下的软件部署：

  这两个程序是通过SOCKET通信，彼此之间有约定一些交互的协议。这个两个程序在内部的业务上是独立的。

现在遇到的问题：

SOCKET_SERVER 程序进行接口升级，改变交互的协议。因此SOCKET_CLIENT程序也要进行修改。

由于写这个程序SOCKET_CLIENT的员工离开公司，对于接手这个程序的人来说，他必须花费一定的时间去熟悉这个程序的逻辑。

如果这个程序的逻辑很负责，则有时很难保证我们所做的修改没有触动原来的逻辑。

因此，我尝试另外的修改的方法，即本文提及的方法。我在上面的软件部署图，加了一个组件。如图：

 其中DECORATOR组件的作用：

1）将SOCKET_CLIENT组件发给SOCKET_SERVER的消息进行协议转换，解编成SOCKET_SERVER需要的消息

MARSHAL---MESSAGE。

2）将SOCKET_SERVER发给SOCKET_CLIENT的消息，进行协议转换，解编成SOCKET_CLIENT需要的消息

MARSHAL---MESSAGE。

这样的修改，就仅仅把时间花在协议的转换，可以大大减低开发时间。因为我们不用花时间去验证修改后的业务，前提是保证协议转换是正确的。

在此，结合前两篇文章，我做了个小总结。该序列文章提到方法的适用性：

1：程序之间的业务是逻辑独立的，而且彼此之间是通过一定的协议交互。

2：彼此之间的交互协议升级后，不触动某一方的逻辑。那么该方程序可以通过DECORATOR方法进行修改，来满足的新的交互协议。

3：在使用这个方法，之前要验证这个方法的可行性。

谢谢大家的阅读，也欢迎大家的建议！