版本：0.1
最后修改：2009-05-15
撰寫：李現民
依賴倒置原則（DIP）告訴我們應該優先依賴于抽象類，而避免依賴于具體類。特別是在一個正在進行開發的應用程序，有很多具體都是非常易變的，因此我們應該依賴于抽象接口，以使我們鐘愛大多數變化的影響。
在典型的面向抽象的程序設計邏輯中，依賴于抽象往往意味著會衍生大量的抽象類及（更大量的）子類，從而構成一些樹狀的類族結構。一個必然會出現的問題是：抽象類族中子類對象由誰創建？
顯然，這不應該交由客戶代碼處理（我們不是要依賴于抽象嘛:)）。一個典型的基于Factory Method解決方案結構如下：
該類圖展現了這樣的一個應用場景：類SomeApp通過接口Shape與ShapeFactory對產品類（Shape類族）進行操作。SomeApp完全沒有使用Square類或者Circle類的任何特定方法。并且由于ShapeFactory的介入，SomeApp對這兩個實現類的創建過程也一無所知。我知道您的疑問：“對具體類ShpeFactoryImplementation的依賴如果處理？”。答案是：工廠類對象往往由main或者由一個隸屬于main的初始化函數創建出來。
使用Factory Method是有代價的：它很復雜，為了創建一個新類，就必須要創建出4個新類，這4個類是：2個表示該新類及其工廠的接口類，2個實現這些接口的具體類。尤其是在一個正在演化的設計的初期，如果缺省使用它們，就會棉套的增加擴展設計的難度。
另一個很常見的問題是：在整個項目的生命周期中，ShapeFactory很可能會自始至終保持僅有ShpeFactoryImplementation一個子類。結果是這帶來了設計上的復雜性，但卻在易于擴展性上得到實際的好處。
一個折衷的解決方案是使用Simple Factory，其類圖結構如下所示：
注意Simple Factory雖然為很多設計模式的書所津津樂道，但其實并不是GOF的23種設計模式之一。同時，聰明的你一定已經發現現在ShapeFactory類已經不再是一個接口了。難道我們又陷入到對具體類的依賴中去了？哦，如果是的話，至少此時我們所依賴的具體類只有ShapeFactory一個，這并不會隨著抽象類Shape子類的增多而增多。
新的問題是：除非ShapeFactory負責所有Shape對象的管理與維護（這時通常應該叫ShapeMan云云。注意：Man for manager，工廠類的命名中不一定要含有Factory字樣的:)），否則它極容易成為一個貧血類----僅僅含有一個CreateShape()函數的類，它披著class的皮，干著function的事。
既然如此，何必要額外創建一個ShapeFactory對象（計算機說：這會降低效率的），把CreateShape() 交給Shape類不就得了？反正是她的孩子，也算天經地義（其實，不完全這樣！）。新的類圖呈現為下面的樣子：
來看看我們的戰果：
-
Factory職能由Shape類承擔。通常CreateShape()可由一個static函數實現；
-
完全消除了非必需類，這避免了創建額外新類的代價；
-
SomeApp類僅依賴一個唯一的類Shape，并且Shape是一個抽象類，這降低了客戶代碼與實現類之間的耦合度；
已知的代價：
-
依賴關系環。敏感的讀者一定已經發現Shape與其實現類之間形成了一種環狀依賴，其代價是每添加一種新的Shape實現就必須修改CreateShape()函數的實現（能夠做到不更改接口）。唯一值得慶幸的是：在Factory Method與Simple Factory的方案中，我們同樣無法避免這種雙向修改；
-
Shape所有權問題。盡管繼承是一種比關聯強得多的實體關系，但在打包時Shape最好與它的客戶代碼SomeApp在一起。SomeApp的實現離不開Shape，但理論上Shape卻是可以脫離Shape單獨存在。依賴關系環的出現會強迫Shape與它的實現類打包在一起；
-
違反了依賴倒置原則（DIP），我們的抽象類開始依賴于具體類；
-
Shape不再是一個接口。如果說Factory Method與Simple Factory中的Shape還有可能是接口的話，那么在最后一方案中具體函數CreateShape()的加入則完全打破了這種可能。
如果：在一個項目演化的初期，您還不確信您需要創建一些Factory類；或者，您已經確信可以承受該方案的代價并且期望得到它所帶來的好處的話，那么您不妨嘗試一下。
參考文獻
-
《敏捷軟件開發 原則、模式與實踐》 P239：FACTORY模式；P279：ABSTRACT SERVER模式；