最近寫tlibrary，有了很多軟體架構方面的思考，也覺得自己在這方面理論知識的不足，從網上down了一本電子書，就叫design pattern，它介紹了很多相關的設計模式，覺得收穫很大，不過，這本書有個缺點，就是敘述過於枯燥，實在不適合閱讀，應該是說是一本不錯的reference book，我想在這裡寫寫我自己學習的體會和理解，有可能不準確，請大家指正，另外部分文字摘自《design pattern》，就此宣告
抽象工廠（abstract factory）
設計模式裡的工廠，是指一種建立物件的介面，抽象工廠則定義了一組用來建立抽象物件的介面，舉個例子，對於下面一組物件
class
product
{}class
producta :
public
product
{}class
productb :
public
product{}
我們按照通常的方式建立物件，則硬編碼了product的具體實現，比如我們要實現視窗換膚，這樣的編碼方式會非常不方便擴充套件
product
*pa
=new
producta;
product
*pb
=new
productb;
現在我們用抽象工廠的方式來建立物件，我們定義乙個虛方法createproduct來負責建立相應的物件
class
factory
}class
productafactory
}class
productbfactory}
這樣我們就可以用下面的方式來建立物件啦，雖然看起來比起上面，我們多寫了很多**，但乙個顯而易見的好處就是我們分離了具體的物件類，所有的建立過程都交給抽象工廠類來負責。
product
*create(factory
*fac)
productafactory faca;
product
*pa
=create(
&faca);
productbfactory facb;
product
*pb
=create(
&facb);
再來說我們上面那個換膚的例子，有了抽象工廠，我們所要做的就是
1. 繼承乙個工廠，建立新**的所有物件
2. 把這個工廠穿給換膚的函式
抽象工廠的缺點也比較容易看到，如果要增加乙個新的物件，需要在抽象工廠的介面中增加乙個create***的新的方法來支援新物件的建立，這就需要更改所有的工廠子類，有一種比較好的方法是，對每種物件定義乙個id，用如下方法建立，相信大家也看到了，這種方法有乙個很大的限制條件就是，所有的物件都要有相同的基類，並且保證強制轉換的正確性
#define
id_prodect_1 10
#define
id_prodect_2 20
class
factory}}
在實現中，有一種情況比較特殊，就是只有乙個工廠來負責建立，不需要繼承新的工廠類，這樣的話，可要把工廠定義成乙個singleton的物件，來訪問，singleton也是設計模式的一種，以後會提到，不過相信很多人也知道了，因為這是比較常用的一種設計模式
最後，貼一張抽象工廠的uml圖，方便大家理解
Design Pattern 工廠模式
當有一些要例項化的具體類，究竟例項化哪個類，要在執行時由一些條件來決定。當 使用大量具體類時，我們就要考慮使用工廠模式了。定義了乙個建立物件的介面，但由子類決定要例項化的類是哪乙個。工廠方法讓類把例項化推遲到子類。public abstract class pizzastore protected ...
design pattern 外觀模式
針對問題 在軟體開發系統中，客戶程式經常會與複雜系統的內部子系統之間產生耦合，而導致客戶程式隨著子系統的變化而變化。那麼如何簡化客戶程式與子系統之間的互動介面？如何將複雜系統的內部子系統與客戶程式之間的依賴解耦？為子系統中的一組介面提供乙個一致的介面，facade 模式定義了乙個高層介面，這個介面使...
design pattern 狀態模式
針對問題 有時候乙個方法可能有很多if.else來判斷狀態後再執行相關操作，當很多方法都重複的出現這樣的if.else判斷時，就可以考慮用狀態模式了。狀態模式的結構圖和策略模式一樣，事實上狀態模式和策略很相似，不同的是狀態模式除了委託狀態外，狀態實體自身持有主實體物件的引用，在狀態實體內部可以動態的...