分佈式軟件設計之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：在使用這個方法，之前要驗證這個方法的可行性。
謝謝大家的閱讀，也歡迎大家的建議！
