19 else
20 instance = null;
21
22 return instance;
23 }
24
25 public abstract Tax CreateTax();
26
27 public abstract Bonus CreateBonus();
28 }
29}
30
這樣，在我們編寫的代碼中就不會出現Chinese，American，Japanese等這樣的字眼了。
小結
最后那幅圖是最終版的系統模型圖。我們發現作為客戶端角色的Calculator僅僅依賴抽象類， 它不必去理解中國和美國企業具體的業務規則如何實現，Calculator面對的僅僅是業務規則接口Tax和Bonus。
Softo系統的實際開發的分工可能是一個團隊專門做業務規則，另一個團隊專門做前端的業務規則組裝。 抽象工廠模式有助于這樣的團隊的分工: 兩個團隊通訊的約定是業務接口，由抽象工廠作為紐帶粘合業務規則和前段調用，大大降低了模塊間的耦合性，提高了團隊開發效率。
完完全全地理解抽象工廠模式的意義非常重大，可以說對它的理解是你對OOP理解上升到一個新的里程碑的重要標志。 學會了用抽象工廠模式編寫框架類，你將理解OOP的精華:面向接口編程.。
應對“新對象”
抽象工廠模式主要在于應對“新系列”的需求變化。其缺點在于難于應付“新對象”的需求變動。如果在開發中出現了新對象，該如何去解決呢？這個問題并沒有一個好的答案，下面我們看一下李建忠老師的回答：
“GOF《設計模式》中提出過一種解決方法，即給創建對象的操作增加參數，但這種做法并不能令人滿意。事實上，對于新系列加新對象，就我所知，目前還沒有完美的做法，只有一些演化的思路，這種變化實在是太劇烈了，因為系統對于新的對象是完全陌生的�！�
實現要點
抽象工廠將產品對象的創建延遲到它的具體工廠的子類。
如果沒有應對“多系列對象創建”的需求變化，則沒有必要使用抽象工廠模式，這時候使用簡單的靜態工廠完全可以。
系列對象指的是這些對象之間有相互依賴、或作用的關系，例如游戲開發場景中的“道路”與“房屋”的依賴，“道路”與“地道”的依賴。
抽象工廠模式經常和工廠方法模式共同組合來應對“對象創建”的需求變化。
通常在運行時刻創建一個具體工廠類的實例，這一具體工廠的創建具有特定實現的產品對象，為創建不同的產品對象，客戶應使用不同的具體工廠。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
