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