“元件協作”模式：

• 現代軟體專業分工之後的第一個結果是“框架與應用程式的劃分”，“元件協作”模式通過晚期繫結，來實現框架與應用程式之間的鬆耦合，使二者之間協作時常用的模式。
• 典型模式
  • Template Method
  • Strategy
  • Observer / Event

Template Method

定一個操作中的演算法的骨架（穩定的），而將一些步驟延遲（容易變化的）到子類中。Template Method使得子類可以不改變（複用）一個演算法的結構即可重新定義（Override覆寫）該演算法的某寫特定步驟
——《設計模式（GoF）》

動機（Motivation）

• 在軟體構建過程中，對於某一項任務，它常常有穩定的整體操作結構，但各個子步驟卻有很多改變的需求，或者由於固有的原因（比如框架與應用之間的關係）而無法和任務的整體結構同時實現。
• 如何在確定穩定操作結構的前提下，來靈活應對各個子步驟的變化或者晚期實現需求？

例子：下面的偽碼主要是有兩個開發人員來構成的程式碼，分別是庫開發人員和應用程式的開發人員。對於庫的開發人員來說，已經開發完成了所需要功能的1、3、5三個步驟；而如果要實現這個完整功能，需要應用程式的開發人員實現其中的2和4這兩步。同時，還需要應用程式的開發者，在使用的時候，依次來呼叫庫和自己開發的這幾個函式。

//程式庫開發人員
class Library{
 
public:
    void Step1(){
        //...
    }
 
    void Step3(){
        //...
    }
 
    void Step5(){
        //...
    }
};
 
//應用程式開發人員
class Application{
public:
    bool Step2(){
        //...
    }
 
    void Step4(){
        //...
    }
};
 
int main()
{
    Library lib();
    Application app();
 
    lib.Step1();
 
    if (app.Step2()){
        lib.Step3();
    }
 
    for (int i = 0; i < 4; i++){
        app.Step4();
    }
 
    lib.Step5();
 
}


 

問題：

1. 首先，對應用程式的開發人員來說，他需要自己開發其中的第二和第五步的函式的開發。對於應用程式的開發者來說，要求是比較高的，必須對庫中的函式情況比較瞭解，重寫的兩個函式的難度也相對較大，對於函式整體執行流程也不被庫函式的開發人員所控制。
2. 最關鍵的問題，庫開發人員和應用程式的開發人員所開發的內容的耦合度很高，彼此相互交織在一起，還需要由用開發人員來組織整體呼叫流程。未來程式的擴充套件性和可維護性的難度都比較大。

解決辦法：

//程式庫開發人員
class Library{
public:
    //穩定 template method
    void Run(){
 
        Step1();
 
        if (Step2()) { //支援變化 ==> 虛擬函式的多型呼叫
            Step3(); 
        }
 
        for (int i = 0; i < 4; i++){
            Step4(); //支援變化 ==> 虛擬函式的多型呼叫
        }
 
        Step5();
 
    }
    virtual ~Library(){ }
 
protected:
 
    void Step1() { //穩定
        //.....
    }
    void Step3() {//穩定
        //.....
    }
    void Step5() { //穩定
        //.....
    }
 
    virtual bool Step2() = 0;//變化
    virtual void Step4() =0; //變化
};
 
//應用程式開發人員
class Application : public Library {
protected:
    virtual bool Step2(){
        //... 子類重寫實現
    }
 
    virtual void Step4() {
        //... 子類重寫實現
    }
};
 
int main()
    {
        Library* pLib=new Application();
        lib->Run();
 
        delete pLib;
    }
}



 

在第一種實現中Application呼叫Library，是一種早繫結。而在第二種方法中，Library呼叫Application，實現的是一種晚繫結。耦合性相對也很低，庫的開發人員完全不需要管應用開發人員的開發情況，可以獨立完成自己的開發任務。對於應用程式的開發人員來說，只需要用簡單的應用即可，而不需要考慮其中具體的實現過程。所以這樣的設計方法的耦合性較低。

注意：對於Template Method來說，有一個前提，就是Run()方法必須要是穩定的。如果Run()不穩定，那麼沒有一個穩定的軟體的骨架，就不存在這樣一種設計模式。假定，所有方式都是穩定，那麼其實也沒有必要使用設計模式。

要點總結：

1. Template Method是一種非常基礎性的設計模式，在面向物件的系統中，有著大量的應用。他用最簡潔的機制（虛擬函式的多型性）為很多應用程式的框架提供了靈活的擴充套件點，是程式碼複用方面的基本實現結構。
2. 除了可以靈活對應子步驟的變化外，“不要呼叫我，讓我來呼叫你”的反向控制結構是Template Method的典型應用。
3. 在具體實現方面，被Template Method呼叫的虛方法可以具有實現，也可以沒有任何實現（抽象方法、純虛方法），一般推薦將他們設定為protected方法。