C 設計模式程式設計之抽象工廠模式新解 3

整合成通用系統

讓我們回顧一下該系統的發展歷程：

最初，我們只考慮將softo系統執行於中國企業。但隨著maxdo公司業務向海外拓展， maxdo需要將該系統移植給美國使用。

移植時，maxdo不得不拋棄中國企業的業務規則類chinesetax和chinesebonus，然後為美國企業新建兩個業務規則類: americantax,americanbonus。最後修改了業務規則呼叫calculator類。

結果我們發現：每當softo系統移植的時候，就拋棄原來的類。現在，如果中國聯想集團要購買該系統，我們不得不再次拋棄americantax,americanbonus，修改回原來的業務規則。

乙個可以立即想到的做法就是在系統中保留所有業務規則模型，即保留中國和美國企業工資運算規則。

通過保留中國企業和美國企業的業務規則模型，如果該系統在美國企業和中國企業之間切換時，我們僅僅需要修改caculator類即可。

讓移植工作更簡單

前面系統的整合問題在於：當系統在客戶在美國和中國企業間切換時仍然需要修改caculator**。

乙個維護性良好的系統應該遵循「開閉原則」。即：封閉對原來**的修改，開放對原來**的擴充套件（如類的繼承，介面的實現）

我們發現不論是中國企業還是美國企業，他們的業務運規則都採用同樣的計算介面。於是很自然地想到建立兩個業務介面類tax，bonus，然後讓americantax、americanbonus和chinesetax、chinesebonus分別實現這兩個介面，據此修正後的模型如下：

此時客戶端**如下：

1 2using system;

3 4namespace inte***cesalary

5 24 }

25}

26 為業務規則增加工廠方法

然而，上面增加的介面幾乎沒有解決任何問題，因為當系統的客戶在美國和中國企業間切換時caculator**仍然需要修改。

只不過修改少了兩處，但是仍然需要修改chinesebonus,chinesetax部分。致命的問題是：我們需要將這個移植工作轉包給乙個叫hippo的軟體公司。由於版權問題，我們並未提供softo系統的原始碼給hippo公司，因此hippo公司根本無法修改calculator，導致實際上移植工作無法進行。

為此，我們考慮增加乙個工具類(命名為factory)，**如下：

1using system;

2 3namespace factorysalary

4 14

15 public bonus createbonus()

19 }

20}

21 修改後的客戶端**：

1 2using system;

3 4namespace factorysalary

5 24 }

25}

26 不錯，我們解決了乙個大問題，設想一下：當該系統從中國企業移植到美國企業時，我們現在需要做什麼？

答案是: 對於caculator類我們什麼也不用做。我們需要做的是修改factory類，修改結果如下：