以 design pattern 來說，Inversion of Control 真正的精神是 template method. 在 GoF 的 <Design Patterns> 中，template method 主要以繼承來達成。但是如果真正理解的話，用 composition 的方式一樣可以達成 template method.

很多文章會把 Dependency Injection 與 Inversion of Control 擺在一起討論 (如上面 link)。主要是因為雖然兩者用意不同 (Dependency Injection 的目的是解除相依性，Inversion of Control 的目的是製造框架)，但常常產出的程式碼會相近，尤其是當 Dependency Injection 被大量使用的時候。

需注意的是，即使是少量的 Dependency Injection, 一樣會伴隨小規模的 Inversion of Control. 所以雖然兩者目的不同，但實為一體之兩面。

References
[1] “Design Patterns”, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

Adapter pattern 的參與 class 為 Target, Adapter, Adaptee. Client 擁有或操作 Target, Adapter 則負責將 Adaptee 的介面轉換成符合 Target 的介面. Adapter pattern 分為兩種架構: 多重繼承的架構為 class adapter, 另一種則為 object adapter. class adapter 同時繼承於 Target 與 Adaptee, 由於是繼承關係, class adapter 較易更改 Adaptee 內部行為. 然而 object adapter 則是包含 (has or can access) Adaptee, 同時繼承於 Target, 所以較強調 Adaptee 的封裝完整. [1] 中有補充 class adapter 無法處理有 sub-classes 的 Adaptee (adapt 其 sub-classes); 關於 object adapter 的是其可以擁有多個 Adaptee.

另外 [1] 中提到利用 class adapter 的架構, Adaptee 與 Target 的角色可互換, 達到雙向 adapt 的功用.

實作須知: class adapter 的做法基本上要 public 繼承 Target, private 繼承 Adaptee.

2. Bridge Pattern
使用時機: 將 base class 的某些 method 拉出來由另一繼承樹實作.

架構範例:

3. Composite Pattern
使用時機: 待處理的物件們可以畫成 Composite-Leaf 樹狀圖.

參與 class 為 Component, Composite 與 Leaf. Composite 與 Leaf 皆繼承 Component, client 只調用 Component 的介面, 另外 Composite 中包含了多個 Component (可以是 Composite 或 Leaf ).

4. Decorator Pattern
使用時機: 須要動態對一物件的某一功能做增強時.

架構範例 (此 pattern 與 Composite Pattern 有幾分相似, 可以比較一下)

References
[1] “Design Patterns”, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.

先了解委託的精神是什麼, from
http://en.wikipedia.org/wiki/Delegation_(programming)

“delegation refers to one object relying upon another to provide a specified set of functionalities. In research, this is often referred to as consultation or as aggregation in modeling.”

另外委託的概念與 Design Pattern 中的 Observer pattern 有關，這部分讀者可以另外再去研讀。

上網查詢了C++關於委託的文章，還是不能充分理解。以下會先介紹微軟官網 C# Delegation 的範例，接著試著將該範例以C++實現，看能否勾勒出C++關於委託的概念。

http://msdn.microsoft.com/zh-tw/library/aa288459(v=vs.71).aspx
在範例一中，

public delegate void ProcessBookDelegate(Book book);

宣告了委託型別，注意他不屬於任一 class, 在調用時

bookDB.ProcessPaperbackBooks(new ProcessBookDelegate(PrintTitle));

BookDB::ProcessPaperbackBooks 的 argument type 為 ProcessBookDelegate. 而 ProcessBookDelegate 的實作則依賴於 “new ProcessBookDelegate(PrintTitle)”, 也就是 PrintTitle. 注意 Test::PrintTitle 是 static function, 不然 compile 時會沒有其位置資訊。

這樣的做法是要 run-time 決定 BookDB::ProcessPaperbackBooks 的行為，而且此行為會受BookDB 物件內容影響。範例一中還有一次委託：

bookDB.ProcessPaperbackBooks(new ProcessBookDelegate(totaller.AddBookToTotal));

這次是傳物件的 method 進 BookDB::ProcessPaperbackBooks.

結論：Delegation (委託) 大致上可以說是從外部傳 static function 或 class method 進要委託工作的人。

要委託工作的人 run-time 調用 delegate function (compile-time 要委託工作的人並不知道 delegate 是誰)，然後此 delegate function 會依照要委託工作的人的狀態工作。

使用時機就如同上述範例一般：當要 run-time 決定要對底下所有物件 (ex: Book) 做不同處理時，可以用 Delegation.

本文我想先討論 [1] chapter 1 中 code reuse 的概念，接下來整理 Abstract Factory，Factory Method，Singleton，Builder，Prototype patterns。

在 [1] chapter 1 中 code reuse 主要分為三大類：Inheritance, Composition, Parameterized Types (Templates)。其中各自的優缺點是：

1. Inheritance

優：繼承關係程式碼可讀性高，架構容易理解。
缺：繼承關係是在 compile-time 就決定，flexibility 低。
缺：sub-class 有權更動 super-class 內部資料與行為，打破封裝。反之，super-class 的更動也會影響 sub-class 的行為。

2. Composition

優：可以在 run-time 再決定 composition objects，flexibility 高。
優：維持 composition objects 的封裝性。
缺：程式可讀性低。

3. Templates

compile-time 定義。

書中的意見是：Composition 是比 Inheritance 好的 reuse 技術，Templates 則提供了第三種選項。我個人認為：Inheritance 與 Composition 使用時機上並不同，有需要更動到 class 內部的要選用 Inheritance，無此需求的時候，當然就是選擇 Composition 了。

接著開始 5 個 design patterns 的討論。

1. Abstract Factory

首先以範例先描述 Abstract Factory。假設麥當勞的一號餐與二號餐會隨著夏季冬季作口味上的調整，則其模型可以如下：

以上例子可以勾勒出 Abstract Factory 的使用時機及好處：

• 生產 product (一號餐二號餐) 的責任完全與系統無關，系統甚至不須知道目前是夏季一號餐還是冬季一號餐，系統只要照著一般一號餐的管理與使用方式即可。以程式語言來說，系統與 factory 和 product 實作完全沒相依性，是很好的設計。
• 系統中所需物件可以被分類。以此範例來說，我們總共有夏季一號餐、冬季一號餐、夏季二號餐、冬季二號餐。很直覺的想法就是把他們分為夏季一組、冬季一組。當系統 configure 成夏季時即產生夏季的餐點，當系統 configure 成冬季時即產生冬季的餐點。

Abstract Factory 實作須知：

• concrete factory 應以 singleton 方式實作。
• Abstract Factory 新增 product 可以改為用參數指定的方式。以上面範例來說，假如要新增夏季三號餐，當然夏季麥當勞廚房要改變，另外麥當勞廚房、冬季麥當勞廚房也要一起變動。所以另一種方式是，兩個 method 生產一號餐與生產二號餐改為生產餐點(餐點號碼)，這樣對單一 concrete factory 的擴充性會方便許多。

2. Factory Method

首先以範例先描述 Factory Method。

顧名思義，Factory Method 著重在 creation function 這個 method。Super-class 有一個 creation function，依照需求利用 sub-class 對此 creation function 做轉型。在未來開發而言，Factory Method 支援 parallel class hierarchies，這是很值得參考的做法。

Factory Method 實作須知：

• 同 Abstract Factory 第二項實作須知，參數化的 creation function 會有彈性很多。
• 使用 Factory Method 會容易產生過多的 sub-class (因為基本上它是與 product type 綁在一起)。此時 sub-class 可以以 template 的方式實作，理論上就會只有一個 template sub-class 了。
• [1]中提到 naming conventions。很多 framework 甚至規定 Factory Method 的 function name，使開發者一看就知道是 Factory Method。很多人可能認為這是小東西，但我個人認為軟體開發程式的基礎建設一定要做好，將來才可以是可管理、可測試的專案。

3. Singleton

Singleton 的範例我想直接用 sample code 來描述。

class Singleton
{
public:
    static Singleton* getInstance( );
protected:
    Singleton( );
private:
    static Singleton* m_instance;
};

Singleton::m_instance = NULL;

Singleton* Singleton::getInstance( )
{
    if( m_instance == NULL )
    {
        m_instance  = new Singleton;
    }
    return m_instance;
}

Singleton 的觀念有兩點要注意的是

1. Singleton 的作法其實就是 global variable 的改良。
2. Singleton 中其實可以放多個 instance. 此時 Singleton 就會多一個管理器的角色。

Singleton 實作上還有很多變化，上述只是基本精神，實際應用上應隨著系統需求而靈活變化才是。

4. Builder

包含一個 director 和一個 builder。client 端擁有一個 director，builder 或以 reference 的形式存在在 director 端裡 (在 director construct 時)，或是當參數傳入。

底下是 client 端的 sample code

// ...
MyDirector1 myDirector1;
MyWorldBuilder builder;
myDirector1.createWorld(builder);
MyWorld world = builder.getWorld( );
// ...

MyWorldBuilder 可能有 buildTrees, buildHouses, buildRivers 等 method。以上例來說，MyDirector1 生成了一種世界，MyDirector2 則會生成另一種世界，with the same MyWorldBuilder

使用時機方面，當最終需求的 product 有如樂高一般可以由不同的 component 所組成時，可以使用此 pattern。director 的 creation function 可以選擇 create product part A and B, 或是 B and C, 或是其他組合。

5. Prototype

Prototype pattern 最重要基本的精神就是使用 Clone method 把自己拷貝一份給 client。Client 需要 create prototype product 時，收到一個 prototype base class 的 pointer，調用 Clone method。

同樣是 run-time 決定要生成哪一個 concrete product 的 design pattern，Prototype pattern 與吃參數的 factory method 差別在哪？

以吃參數的 factory method 來說，client 會知道要生成哪一個 concrete product。因為通常 factory 會存在在 client 中，所以 factory method 的參數會經過 client。另外，client 也許也要確認 factory 是否支援此參數。

以 Prototype pattern 來說，client 完全不知到目前要生成哪一個 concrete product，也沒有要確認任何 concrete product 相關正確性的責任。

結論：Prototype pattern 會簡化系統 (client) 的設計與工作。但工作不會憑空消失，Prototype pattern 把相關的工作移到了類似 prototype manager 的模組去做。

在一般情形中，我個人還是會使用吃參數的 factory method。但在生成物件極度動態的情形下 (Ex: 依照 config 不同而不同，依照 branch 不同而不同)，則會使用 Prototype pattern。

最後實作時要注意的一點是，C++ copy constructor 是 member-wise copy。但是 Clone method 所需的是 deep copy，實作時要稍微注意一下。

[1] “Design Patterns”, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides.