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