|
|
從耦合關(guān)系談起
耦合關(guān)系直接決定著軟件面對(duì)變化時(shí)的行為
-模塊與模塊之間的緊耦合使得軟件面對(duì)變化時(shí)，相關(guān)模塊都要隨之更改
-模塊與模塊之間的松耦合使得軟件面對(duì)變化時(shí)，一些模塊更容易被替換或者更改，但其他模塊保持不變
抽象部分變化慢，細(xì)節(jié)（具體）部分變化快；高層部分變化慢，底層部分變化快。
當(dāng)我們對(duì)于系統(tǒng)的認(rèn)識(shí)無(wú)法梳理出上面的圖時(shí)，最好不要一開(kāi)始就用設(shè)計(jì)模式，設(shè)計(jì)模式其實(shí)是一個(gè)演繹的過(guò)程。當(dāng)我們對(duì)軟件認(rèn)識(shí)不斷深化時(shí)，慢慢就會(huì)知道哪些是主要的，哪些是次要的，就能梳理出一個(gè)抽象和具體的層次，再考慮用哪種設(shè)計(jì)模式。
第二幅圖滿(mǎn)足了依賴(lài)倒置原則，中間的主線(xiàn)是變化慢的部分，分支都是用接口相連。這樣的松耦合使得模塊與模塊之間的連接用接口連接，接口是相對(duì)穩(wěn)定的部分，接口的實(shí)現(xiàn)是相對(duì)變化的部分。例如：去幫我買(mǎi)一條毛巾，只告訴了是毛巾這樣事物，而毛巾的具體品種、顏色并沒(méi)有具體的需求。大自然創(chuàng)造的世界，遍地都是松耦合、高內(nèi)聚。例如屋子里的凳子和桌子、床單和被子等，當(dāng)我們需要換床單時(shí)，是不需要換床的。床和床單之間有一個(gè)接口，床是主線(xiàn)，床需要床單的接口，只要具體的床單滿(mǎn)足這個(gè)尺寸接口，就可以接上。主邏輯的變化成本比輔邏輯的變化成本高，所以盡量讓輔邏輯的變化較少的影響主邏輯。因此我們?cè)O(shè)計(jì)軟件的原則是，先穩(wěn)定下接口，再考慮具體實(shí)現(xiàn)。
動(dòng)機(jī)（Motivation）
在軟件系統(tǒng)張中，經(jīng)常面臨著“某個(gè)對(duì)象”的創(chuàng)建工作：由于需求的變化，這個(gè)對(duì)象（的具體實(shí)現(xiàn)）經(jīng)常面臨著劇烈的變化，但是它卻擁有比較穩(wěn)定的接口。如何應(yīng)對(duì)這種變化？如何提供一種“封裝機(jī)制”來(lái)隔離出“這個(gè)易變對(duì)象”的變化，從而保持系統(tǒng)中“其他依賴(lài)對(duì)象的對(duì)象”不隨著需求改變而改變？
結(jié)構(gòu)（Structure）
例說(shuō)Factory Method應(yīng)用
汽車(chē)
汽車(chē)測(cè)試
但是這種測(cè)試只能測(cè)試一種Car，如果要測(cè)試其他類(lèi)型的Car，需要修改代碼并重新編譯。為了應(yīng)對(duì)這種改變，我們需要把Car先變成抽象類(lèi)。
然后我們?cè)诳蛻?hù)程序使用的時(shí)候，把所有的Car都換成抽象的AbstractCar，這樣客戶(hù)程序就不需要了解具體測(cè)試的是哪個(gè)Car了。客戶(hù)程序如下
但這種代碼明顯是錯(cuò)誤的，抽象類(lèi)不能直接實(shí)例化，因此我們比較好的方法是把抽象的Car傳遞進(jìn)來(lái)
如果現(xiàn)在我們需要Car的多個(gè)實(shí)例，那么參數(shù)只接收一個(gè)抽象的Car就顯得不那么適用了。我們可能想到的方法是把傳進(jìn)來(lái)的Car做一個(gè)淺拷貝Memberwise，但是淺拷貝是一個(gè)protected方法，并且不能拷貝引用，但是這也是有辦法解決的，這種克隆的做法可以，但是現(xiàn)在我們研究另一種做法。我們希望能有一個(gè)創(chuàng)建Car的工廠(chǎng)，這樣我們?cè)诳蛻?hù)程序就不需要關(guān)心Car的實(shí)例，只管用這個(gè)工廠(chǎng)去創(chuàng)建具體的Car。
Car的具體實(shí)現(xiàn)
Car工廠(chǎng)
（糾正：CarFactory類(lèi)中的CreateCar方法應(yīng)該返回抽象的AbstractCar類(lèi)型，CarFactory的類(lèi)和具體HongqiCarFactory的類(lèi)在實(shí)際中應(yīng)該放在兩個(gè)不同的文件夾中）
因?yàn)榭蛻?hù)程序需要用到CarFactory，所以CarFactory中不應(yīng)該涉及到Car的具體實(shí)現(xiàn)，CarFactory應(yīng)該是一個(gè)抽象的工廠(chǎng)類(lèi)，因此HongqiCar的工廠(chǎng)需要一個(gè)繼承自抽象CarFactory的具體工廠(chǎng)。在應(yīng)用程序調(diào)用的時(shí)候，傳入客戶(hù)程序的工廠(chǎng)應(yīng)該是具體的HongqiCarFactory工廠(chǎng)。
當(dāng)想換具體Car的時(shí)候，只需要?jiǎng)?chuàng)建一個(gè)新的Car繼承自AbstractCar，并新建一個(gè)具體CarFactory工廠(chǎng)繼承自抽象CarFactory。然后在具體的應(yīng)用中把具體的Car工廠(chǎng)參數(shù)修改即可。當(dāng)然，完全可以讓具體應(yīng)用的代碼也不用修改，把變化轉(zhuǎn)嫁到配置文件中去。
Factory Method模式的幾個(gè)要點(diǎn)
Factory Method模式主要用于隔離類(lèi)對(duì)象的使用者和具體類(lèi)型之間的耦合關(guān)系。面對(duì)一個(gè)經(jīng)常變化的具體類(lèi)型，緊耦合關(guān)系會(huì)導(dǎo)致軟件的脆弱。
Factory Method模式通過(guò)面向?qū)ο蟮氖址ǎ瑢⑺獎(jiǎng)?chuàng)建的具體對(duì)象工作延遲到子類(lèi)，從而實(shí)現(xiàn)一種擴(kuò)展（而非更改）的策略，較好地解決了這種緊耦合關(guān)系。
Factory Method模式解決“單個(gè)對(duì)象”的需求變化；
AbstractFactory模式解決“系列對(duì)象”的需求變化；
Builder模式解決“對(duì)象部分”的需求變化；
.NET框架中的Factory Method應(yīng)用
it知識(shí)庫(kù)：C#面向?qū)ο笤O(shè)計(jì)模式縱橫談：Factory Method 工廠(chǎng)方法模式，轉(zhuǎn)載需保留來(lái)源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。
