4/17/2010

Policy-Based Class Design

在C++新增template功能的初期,大家普遍認為template只是為物件導向設計得到更好的重用性,不單單將重複使用的程式碼設計成物件類別(class),連類別也重用,經由編譯器幫programmer把不同型別但功能完全相同的程式碼複製。如standard template library裡的vector,宣告vector就是一個存intergerarray的向量,宣告vector就是一個存character pointer array的向量,各自均在insert, earse等功能相同的介面。

其後有意無意間大家發現template能做的事情不單單如此,甚至出乎意料之外的強大,如使用LISP之類的技巧令編譯器幫你在編譯期運算,或編譯期才組合產生你所需要的程式碼。

在大型長期開發的軟體中,保持架構效能延展性介面一致十分重要,可是軟體設計必定不斷變動,功能的擴充、模組的更換尤其繁甚,為了加插功能、修改模組,結果往往就是架構變型,效能降低,介面不一致,元件肥大。(更可怕的是為求擴充,不斷新增介面,混亂不堪,日後維護困難,難以接手)

Policy-Based Class Design是一種新思維的設計方法,藉由template把各種小行為在編譯期組合成為功能複雜的元件,具有高度的效能和彈性。這種設計分為兩部份 ── policies, host class。policies是一些小型的類別,只單純負責某一核心功能,獨立運作的「策略」,如設計模式 (Design Pattern) 中的行為模式 (behavioral pattern) 或結構模式 (structural pattern),而host class像是一個外殼,由多個policies組成,針對特定主題,定義通用介面和錯綜複雜的邏輯流程,核心功能的細節完全經由組合的policies來實現。這種程式設計就像現實生活中的大公司,主管就是host class,為了完成專案找了幾個小將(policies)回來,排行程,分配資源,協調工作,開會擋箭,追殺廠商等,小將只要完成專案裡的需求就好了。(真完美)


現在來看看軟體裡經常會遇到的案例,假設軟體需要存儲設定,一開始決定使用ini格式,因此普遍會寫一個ConfigManager,提供寫入、擷取和操作介面。
class ConfigManager {
public:
    BOOL Load(char* path);
    void Write(char* path);

    BOOL Add(char* columeName, char* columeValue);
    char* columeValue Query(char* columeName);
};
如果考慮到延展性,ConfigManager將會繼承Load()和Write()這兩個單獨功能的類別。但這樣有一個缺點ConfigManager會繼承IniLoader和IniWriter裡所有公開介面,介面被破壞。
class ConfigManager : public IniLoader, public IniWriter {
public:
    BOOL Add(char* columeName, char* columeValue);
    char* columeValue Query(char* columeName);
};

class IniLoader {
public:
    virtual BOOL Load(char* path);
};

class IniWriter {
public:
    virtual BOOL Write(char* path);
};
除了使用多重繼承外,也可使用組合物件方式。
class ConfigManager {
public:
    BOOL Load(char* path) {
        if (IsExist(path))
            m_iniLoader.Load(path);
    }
    void Write(char* path) {
        if (IsExist(path))
            m_iniWriter.Write(path);
    }

    BOOL Add(char* columeName, char* columeValue);
    char* columeValue Query(char* columeName);

private:
    IniLoader m_iniLoader;
    IniWriter m_iniWriter;
};
其後軟體需要更換模組,假設由Ini改為Xml,還需要自動從Ini升級到Xml喔。所以可能會設計抽象類別BaseLoader和BaseWriter,IniLoader, XmlLoader, IniWriter, XmlWriter分別繼承抽象,並傳入ConfigManager中,讓上層去決定使用那種Loader和Writer。
class ConfigManager {
public:
    ConfigManager(BaseLoader* pLoader, BaseWriter* pWriter) {
        m_pLoader = pLoader; m_pWriter = pWriter;
    }

    BOOL Load(char* path) {
        if (IsExist(path))
            m_iniLoader.Load(path);
    }
    void Write(char* path) {
        if (IsExist(path))
            m_iniWriter.Write(path);
    }

    BOOL Add(char* columeName, char* columeValue);
    char* columeValue Query(char* columeName);

private:
    BaseLoader* m_pLoader;
    BaseWriter* m_pWriter;
};

class BaseLoader {
public:
    virtual BOOL Load(char* path) = 0;
};

class BaseWriter {
public:
    virtual BOOL Write(char* path) = 0;
};
現在的設計看起來一切都很好,可怕的事情發生了,針對Xml的讀入處理,ConfigManager需要提供一個介面Fix(),這時介面的一致性就被破壞了,如果使用一開始所說的多重繼承,則必須宣告四個不同的類別才能令介面保持一致性。如果未來還新增網路讀取功能NetLoader, NetWriter,就必須宣告 2 * 2 * 2 個不同類別了,這不就正好是template的能力嗎。

”令軟體存在數種不同版本的設計實作方案,每次只從中選擇其一的方案,而又需要保持切換與擴充的彈性”就是Policy-Based Class Design的中心思想。Policy-Based Class Design的設計如下,ConfigManager是host class,IniLoader, IniWriter, XmlLoader和XmlWriter是policies。
template<class Loader, class Writer>
class ConfigManager : public Loader, public Writer {
public:
    BOOL Load(char* path) {
        if (IsExist(path))
            m_iniLoader.Load(path);
    }
    void Write(char* path) {
        if (IsExist(path))
            m_iniWriter.Write(path);
    }

    BOOL Add(char* columeName, char* columeValue);
    char* columeValue Query(char* columeName);
};

class XmlLoader {
public:
    BOOL Load(char* path);
    BOOL Fix();
};
void main() {
    ConfigManager<Xmlloader, Iniwriter> c1;
    ConfigManager<Iniloader, Xmlwriter> c2;
    ConfigManager<Xmlloader, Netwriter> c3;

    c1.Load("xxx");
    c1.Fix();
    c2.Load("xxx");
    c2.Fix();    // compile error
    c3.Load("xxx");
    c1.Write("xxx");
    c2.Write("xxx");
    c3.Write("xxx");
}
看到這裡總會有點點卡住,到底Polymorphism Design和Policy-Based Class Design有甚麼差別呢。其實兩者之間有著極大的差異,如果說繼承體系是上而下 (top down)構成,介面由Base class定義,由Derived class實作,那麼Policy-Based Class就是下而上 (bottom up)構成,介面由Host class定義,由Policy class實作。Host class會繼承它所需的policies,並且在Host class中定義出操作行為的骨架流程,至於真正的實作細節,則全權委派 (delegate)給policies進行處理。架構恰好完全與繼承體系方向相反

上述例子中還不算最終形式的Policy-Based Class Design,就像遞迴一樣的概念,tempate也可以是多層的,經由Host class傳遞template parameter給polices來逹到,能組合出更多的功能。(這種組合可是次方級數成長的喔),如下,現在不再統一一起寫設定檔,改為每個元件單獨讀寫。
template<class Loader, class Writer, class Componet>
class ConfigManager : public Loader<Componet>, public Writer<Componet> {
public:
    BOOL Load(char* path) {
        if (IsExist(path))
            m_iniLoader.Load(path);
    }
    void Write(char* path) {
        if (IsExist(path))
            m_iniWriter.Write(path);
    }

    BOOL Add(char* columeName, char* columeValue);
    char* columeValue Query(char* columeName);
};

template<class Componet>
class IniLoader {
public:
    BOOL Load(char* path) {
        Componet::GetConfigInfo();
        // do something
    }
};
void main() {
    ConfigManager<XmlLoader, IniWriter, Schedular> c1;
    ConfigManager<IniLoader, XmlWriter, Recorder> c2;
    ConfigManager<IniLoader, NetWriter, RemoteServer> c3;

    c1.Load("xxx");
    c1.Fix();
    c2.Load("xxx");
    c2.Fix();    // compile error
    c3.Load("xxx");
    c1.Write("xxx");
    c2.Write("xxx");
    c3.Write("xxx");
}
說穿了Policy-Based Class Design的基本原理就是Strategy Pattern,如果現在需要的策略只有一個,那整個Host class就跟Strategy Pattern十分類似,也沒有必要使用Policy Design了。但是,如果現在需要的策略是兩個以上,還繼續使用Strategy Pattern反而會降低效能,元件肥大,日後難以維護。而Policy-Based Class Design就是使用template幫你組合程式碼,把多個Strategy Pattern組合成為一個類別,同時減低設計的相依性。

總結一下Policy-Based Class Design的優缺處
1. 高顆粒性 (granularity),核心功能獨立運作,方便unit test。
2. 高延展性。只要架構不變,新增功能、更換模組和小修改,只要寫Policy class就可以了。
3. 高擴充性。這是進階主題,下回再說。
4. 介面一致。每一個ConfigManger有一致的共用介面,定義在Host class裡,同時,對於特定某種ConfigManager能從繼承中獲得額外的介面,別與其他ConfigManager,又能保持介面完整。
5. 介面高彈性。這是進階主題,下回再說。
6. 高效能。每一個ConfigManager的介面和實作由繼承而來,避免透過成員變數中的抽象類別間接呼叫。值得注意的是Host, Policy class基本上是不用(也不需要)虛擬函式,直接免除virtual table的間接呼叫和記憶體使用量。
7. Host class實作技巧高。Host class使用到template,比直接寫一般的C++難。
8. 實作思想需要改變。Policy class非常獨立,常常是沒有任何成員變數,只實作行為,資料由參數傳入,回傳結果。

沒有留言: