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

                                      分布式软件设计之DECORATOR模式

   本人在工作过程中，修改了一个SOCKET通信的程序。这个程序和其他程序之间的关系如以下图（1）描述的模式。

    

                                                       图（1）

图（1）模块说明：

 1：客户端，是一个类似电话的终端。每次与其他通信设备通信之前都必须到监控中心获取余额，判断余额是否足于下次的通信。

2：监控中心负责根据客户端的请求到局方那里去查询余额，并根据一定计算规则计算该客户端的余额是否足于下次的通信，并返回结果给客户端。

3：局方是负责根据监控中心的请求，查询用户的余额信息，是其他公司的模块。

现在的问题：

1：局方对监控中心的socket连接是短连接。因此监控中心调用recv的时候，恰巧被关闭，会返回0，并错误地将该事件认为是对方发送的数据不合法。由于是短连接，所以客户端经常接收到不能进行下次通话的回复。

2：监控中心对客户端每个请求都到局方查询一次结果。如果对于某一个客户端的余额比较多的情况下，在短时间内应该不用再次查询，就可以判断是否可以继续下一次的通信，而这个功能在监控中心中没有实现。

3：监控中心在发送客户短请求到局方的时候的机制最多一次重复机制。如果第一次失败是SOCKET错误，就重新连接局方。再进行第二次的发送请求。这样如果在网络不通畅的情况，延长对客户端回包的响应时间。

而监控中心是我公司开发的程序，我负责修改。由于任务比较紧，我仅仅使用传统的修改方法，修改（1）的问题。如果是recv调用返回0的时候重新连接局方，重新发送一次请求，再重新recv一次。

现在介绍一个新的方法，再介绍这个方法之前，先提及设计模式中的DECORATOR模式。

    DECORATOR模式：

 1）意图，动态地给一个对象添加一些额外的职责。就增加功能来说，DECORATOR模式相比生成子类更为灵活。

2）适应性，在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

关于DECORATOR模式详细资料可以参看《设计模式------可复用面向对象软件的基础》

  现在介绍上述提及的新方法。由于图（1）程序之间的通信是基于通信。

因此，只要是满足彼此之间的通信结果是一致的，我们可以采用以下的模式：