>>>  技術話題—商業文明的嶄新時代  >>>

簡體     傳統

2005.12.30 李建忠

依賴關系的倒置

抽象不應該依賴于實現細節，實現細節應該依賴于抽象。

-抽象A直接依賴于實現細節b（軟件易脆，很容易需要重新編譯）

-抽象A依賴于抽象B，實現細節b依賴于抽象B

動機（Motivation）

在軟件系統中，經常面臨著“某些結構復雜的對象”的創建工作；由于需求的變化，這些對象經常面臨著劇烈的變化，但是它們卻擁有比較穩定一致的接口。

如何應對這種變化？如何向“客戶程序（使用這些對象的程序）”隔離出“這些易變對象”，從而使得“依賴這些易變對象的客戶程序”不隨著需求改變而改變？

意圖（Intent）

使用原型實例指定創建對象的種類，然后通過拷貝這些原型來創建新的對象

——《設計模式》GoF

結構（Structure）

例說Prototype應用

上面的代碼，GameSystem依賴于具體的new的對象，如果面臨對象變化，例如如果要增加一個新的角色，就要重新修改編譯了。對此，我們就可以用工廠方法來改變，但是，對于每一個類型都要寫一個工廠類，比較繁瑣。我們也可以用抽象工廠方法，創建一組對象。但這里我們選擇使用原型模式。

先把GameSystem里用到的類型換為抽象類型。

再將需要new的具體對象用參數傳入，這樣在GameSystem這個客戶程序里面就只依賴于抽象而不依賴于具體了。具體的NormalActorA、FlyActorA等都不出現在GameSystem中。

應用程序

給抽象類增加Clone抽象方法

給具體類實現Clone方法

但有一點要注意，MemberwiseClone方法只是一種淺拷貝，它只能拷貝所有的值類型和String，如果是引用類型（例如數組），它就會只拷貝引用，而不會重新創建對象，例如對數組，就只會拷貝數組的地址。

如下圖，左邊是棧，右邊是堆，（.NET的類都是在堆上）

如果想深拷貝，除了用笨辦法，還可以用序列化的方式來做。首先需要把類標記為可序列化，然后將類序列化到內存，再把內存中的類反序列化，反序列化得到的對象和原來的對象一定是深拷貝。

在對于結構中的圖，可以對應為：Client就是GameSystem，Operation方法就是Run。Prototype抽象類就對應NormalActor，ConcretePrototype即NormalActorA。

Prototype模式的幾個要點

Prototype模式同樣用于隔離類對象的使用者和具體類型（易變類）之間的耦合關系，它同樣要求這些“易變類”擁有“穩定的接口”。

Prototype模式對于“如何創建易變類的實體對象”（創建型模式除了Singleton模式以外，都是用于解決創建易變類的實體對象的問題的）采用“原型克隆”的方法來做，它使得我們可以非常靈活地動態創建“擁有某些穩定接口”的新對象——所需工作僅僅是注冊一個新類的對象（即原型），然后在任何需要的地方不斷地Clone。

Prototype模式中的Clone方法可以利用.NET中的Object類的MemberwiseClone()方法或者序列化來實現深拷貝。

有關創建型模式的討論

Singleton模式解決的是實體對象個數的問題。除了Singleton之外，其他創建型模式解決的都是new所帶來的耦合關系。

Factory Method，Abstract Factory，Builder都需要一個額外的工廠類來負責實例化“易變對象”，而Prototype則是通過原型（一個特殊的工廠類）來克隆“易變對象”。（其實原型就是一個特殊的工廠類，它只是把工廠和實體對象耦合在一起了）

如果遇到“易變類”，起初的設計通常從Factory Method開始，當遇到更多的復雜變化時，再考慮重構為其他三種工廠模式（Abstract Factory，Builder，Prototype）。

一般來說，如果可以使用Factory Method，那么一定可以使用Prototype。但是Prototype的使用情況一般是在類比較容易克隆的條件之上，如果是每個類實現比較簡單，都可以只用實現MemberwiseClone，沒有引用類型的深拷貝，那么就更適合了。Prototype如果要實現深拷貝，還需要在每個要克隆的類上加序列化標簽，這點復雜度要考慮進程序中。

2010.9.28

MSDN 網絡廣播 李建忠 2013-08-22 08:44:05