續上集未完的相關設計模式...
Composite 模式
延續先前的電器比喻。現在，如果希望 UPS 不只接電腦，還要接電風扇、除濕機，可是 UPS 卻只有兩個電源輸出孔，怎麼辦？
我們可以買一條電源延長線，接在 UPS 上面。如此一來，電風扇、除濕機、和電腦便都可以同時插上延長線的插座了。這裡的電源延長線，即類似Composite Pattern（組合模式），因為電源延長線本身又可以再連接其他不同廠牌的延長線（這又是因為插座皆採用相同介面），如此不斷連接下去。
呃….延長線的比喻有個小問題：它在外觀上看起來也像是層層串接，容易和 Decorator 模式混淆。事實上，這兩種設計模式在結構上的確有相似之處。下圖所示為 Composite 模式的結構圖。
由此結構圖可以看得出來，Composite 模式 其實是個樹狀結構，呈現的是「整體－包含」（whole-part）的關係。樹上的每個節點（Leaf）都實作了相同的介面，而每個節點又可以包含多個子節點；就像檔案目錄結構那樣，每個資料夾底下都可以有零至多個資料夾。相較之下，Decorator 模式則是讓裝飾者看起來長得和被裝飾者一樣，但其實加上了額外的修飾。
Adapter 模式
當你的手機沒電，需要充電時，就算有電源延長線也沒用，因為手機充電時所需的電壓並不是一般家庭用電的 110 伏特交流電壓。此時我們通常會使用手機隨附的變壓器（adapter），將變壓器的電源插頭插在牆壁的電源插座，然後將變壓器的另一端連接至手機。像這樣把一種規格（介面）轉換成另一種規格的設計，就叫做Adapter Pattern（轉換器模式）。下圖所示為 Adapter 模式的結構。
仍使用先前 logging 範例來說明。假設我們沒有實作自己的 logging API，而是直接使用第三方元件。然而，考慮到將來很可能會改用另一套 logging 元件，於是決定使用 Adapter 模式來保護自己的程式碼。首先，必須先訂出 logging API 的介面，讓應用程式只針對此介面來寫入 log。此介面只定義了一個寫入日誌的方法，叫做 Log，參考以下程式片段。
public interface ILogger
{
void Log(string msg);
}
接著設計 Adapter 類別。此類別須實作 ILogger 介面，並且在 Log 方法中轉而呼叫第三方元件的方法。程式碼如下：
public class CommonLogger : ILogger
{
private ThirdPartyLogger logger = new ThirdPartyLogger();
public void Log(string msg)
{
logger.WriteEntry(msg); // 轉呼叫第三方元件的方法。
}
}
如此一來，以後如果真的需要改用另一套 logging 元件，程式修改的範圍就只限定在 CommonLogger 類別而已。
Factory 模式
第一章曾經提過，每當我們在程式中使用 new 運算子來建立類別的執行個體，我們的程式碼就在編譯時期跟那個類別固定綁（繫結）在一起了。其實用 new 來建立物件還有個缺點：C# 的建構函式名稱就是類別名稱，不可任意命名；於是當類別有數個多載的（overloaded）建構函式時，光是閱讀傳入建構函式的參數列，有時不見得那麼容易明白程式的意圖。舉例來說：
var user1 = new User("Mike", 101, true);
var user2 = new User("Jane", 102, flase);
不如下列程式碼清楚：
var user1 = UserFactory.CreateAdministrator("Mike", 101);
var user2 = UserFactory.CreateDomainUser("Jane", 102);
其中的 UserFactory 就是擔任物件工廠的角色，它是個 static 類別，且唯一的任務就是生產特定類型的物件。程式碼如下所示。
public static class UserFactory
{
public User CreateAdministrator(string name, int id)
{
// 略
}
public User CreateDomainUser(string name, int id)
{
// 略
}
}
一般而言，Factory 模式泛指各種能夠生產物件的工廠，通常有三種模式：Factory Method（工廠方法）、Simple Factory（簡單工廠）、和 Abstract Factory（抽象工廠）。剛才的 UserFactory 就是一個 Simple Factory。
Note: 假設我們完全不知道 DI，或者覺得沒必要使用 DI，可是又希望程式碼不要和特定實作類別綁太緊（不想要直接 new 一個物件），此時 Factory 模式通常是個值得考慮的方案。實作 Factory Method 模式時，通常會在一個基礎類別中定義建立物件的抽象方法（難怪叫做「工廠方法」），然後由各個子類別來實作該方法。若將先前的 UserFactory 改成以 Factory Method 來實作，其類別結構如下圖所示。
Abstract Factory 比前面兩種工廠模式要稍微複雜一些，它是用來建立多族系的相關或相依物件，且無須指名物件的具象類別。實作此模式時，會將一組建立物件的方法定義成一個介面，代表抽象工廠。然後，你可以撰寫多個類別來實作該介面，而這些類別的角色就像真實世界中的工廠，類別中的每一個工廠方法則有點像是真實工廠裡的一條生產線。當用戶端需要建立該族系的物件時，就是利用其中一種具象工廠（concrete factory）來生成物件。此外，由於具象工廠都實作了同一組介面，所以用戶端甚至可以在執行時期動態切換成不同的工廠，以建立一組相關的物件。
OK! 設計模式的部分就概略介紹到此，後續章節中如碰到其他模式，也會一併介紹（例如 Strategy、Repository、Service Locator 等等）。
「我曾在這樣的十字路口：努力學習各種模式，希望成為一個更好的軟體設計師；但現在，為了真正成為更優秀的軟體設計師，我必須降低對模式的依賴。」
—— Joshua Kerievsky. 《Refactoring to Patterns》 作者
from : http://huan-lin.blogspot.com/2011/10/dependency-injection-4.html
沒有留言:
張貼留言