• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            在寫DirectUI時有這么一個需求,就是加載一串XML,如何生成一棵對應的控件樹?

            比如XML如下:

            <panel>

                   <button id=”1” text=”button”/>

            <label id=”2” text=”label”/>

                  <panel>

                        <label id=”3” text=”good”/>

                    </panel>

             

            </panel>

            如何生成對應的Control Tree?

             

            看到這個,我們首先想到的是先對這個控件層次體系進行設計, 并抽象出如下層次:

            Class CControlBase

            {};

             

            Class CButton: public CControlBase

            {};

             

            Class CLabel: public CControlBase

            {};

             

            Class CContainer: ControlBase

            {};

             

            Class CPanel: public CContainer

            {};

             

            我們可以看到他們的控件類層次如下:

            以上層次符合一般面向對象設計的規則,其中CContainer表示控件容器類的基類。

            那么如何根據XML創建這些對象呢?

            我們想到了抽象工廠(Abstract Factory), 定義如下:

            Class CControlFactory

            {

            Public:

                   CButton* CreateButton() { return new CButton;}

                   CLabel* CreateLabel() { return new CLabel;}

                   CPanel* CreatePanel() { return new CPanel;}

            }

             

            顯然,以上設計每次加入一個新控件都要重新加一個Create方法,不符合面向對象設計的開放封閉原則(OCPOpen Closed Principle), 因此我們把它改成下面的接口:

            Class CControlFactory

            {

            Public:

                   CControlBase* CreateControl(const string& strTypeName)

            {

                          If(strTypeName==”button”)

            return new Button;

                          Else if(strTypeName==”label”)

            return new Label;

                          Else if(strTypeName==”panel”)

            return new Panel;

                          Else

                                 Return null;

            }

            };

             

            顯然上面的設計盡管比前一個好多了, 但是仍然有硬編碼(hard code)的味道, 每次新加一個控件,都要在這里改代碼。

             

            如何才能新加控件,又不影響這里的代碼呢?

            我們想到了注冊機制, 設計如下:

            Class CControlFactory

            {

            Public:

                   Bool RegisterControl(const string& strTypeName, void* lpfnCreateFun);

                   CControlBase* CreateControl(const string& strTypeName) ;

             

            Protected:

                   map<string, void*> m_controlMap;

            };

            我們看到我們上面的設計是通過注冊控件和它的創建方法,保存在一個Map里,然后在CreateControl時通過查詢這個Map,調用控件注冊的創建方法, 來生成新控件。

            可以看到上面的設計已經完全符合開放封閉原則,我們新加控件完全不會影響現有的代碼。

             

            但是考慮這樣一個需求,要求新生成控件要有默認風格,并且這些風格是可變的,比如我們要生成的Button 默認風格是要求以某個圖片為背景。

             

            顯然上面注冊創建函數的方法滿足不了我們這里的需求,因為我們不可能通過在我們的創建函數里硬編碼來指定初始控件風格。

             

            怎么樣才能讓我們新創建的控件有默認風格,并且該默認風格是可變的?

            我們想到了設計模式里創建型模式中的原型(Prototype)模式, 給我們的基本控件增加一個Clone方法, 代碼如下:

            Class CControlBase

            {

            Public:

                   Virtual CControlBase* Clone() { return new CControlBase(*this);}

            };

             

            Class CButton: public CControlBase

            {

            Public:

                   Virtual CControlBase* Clone() { return new CButton (*this);}

            };

             

            Class CLabel: public CControlBase

            {

            Public:

                   Virtual CControlBase* Clone() { return new CLabel (*this);}

            };

             

            Class CContainer: ControlBase

            {

            Public:

                   Virtual CControlBase* Clone() { return new CContainer (*this);}

            };

             

            Class CPanel: public CContainer

            {

            Public:

                   Virtual CControlBase* Clone() { return new CPanel (*this);}

            };

             

            而我們ControlFactory的設計如下:

            Class CControlFactory

            {

            Public:

                   Bool RegisterControl(const string& strTypeName, CControlBase* pPrototypeControl);

                   CControlBase* CreateControl(const string& strTypeName) ;

             

            Protected:

                   map<string, CControlBase*> m_controlMap;

            };

            可以看到在注冊時我們把控件原型保存起來,然后在CreateControl時通過該控件原型的Clone方法,創建我們的新控件。這種設計下,我們只要在注冊時提供不同的原型控件,后面創建時就有不同的默認風格,非常方便。

             

            至此,我們基本完成了ControlFactory的工作。

            這里還可以優化的是這里的ControlFactory我們可以把它定義成單例(Singleton:

            Class CControlFactory

            {

            Public:

                   Static CControlFactory* GetInstacne();

            Public:

                   Bool RegisterControl(const string& strTypeName, CControlBase* pPrototypeControl);

                   CControlBase* CreateControl(const string& strTypeName) ;

                  

            Protected:

                   map<string, CControlBase*> m_controlMap;

            };

             

            有了Control層次和Control Factory,我們接下來考慮如何解析XML來生成Control Tree?

            一般的設計會寫一個如下的類:

            Class CControlBuilder

            {

                   Public:

                          CControlBase* BuildControlTree(const string& strXML);

            };

            上面的設計直接通過傳入XML,生成Control Tree,看起來很完美。

             

            但是顯然這里有2件事情要做,一件是XML的解析,另一件是Control Tree的生成。我們把這2個東西柔在一個類里面,對我們以后維護很不方便。

             

            比如說我們本來用TinyXML來解析XML的,但是后來發現它是基于DOM的,效率太低,想改用別的XML解析器,這時你就會發現修改CControlBuilder這個類是多么痛苦了。

             

            顯然,我們比較好的設計是我們應該把XML解析和Build Control Tree2個功能分離開來,這也符合面向對象設計時的單一職責原則(Single Responsibility Principle)

             

            我們抽象出一個XML的解析接口:

             

            Class IXMLParser

            {

                   Public:

                          Virtual bool SetDoc(const cstring& strXML);

                          Virtual string GetTagName();

                   Virtual bool FindElem(const string& strName );

                   Virtual bool FindChildElem(const string& strName );

                   Virtual bool IntoElem();

                   Virtual bool OutOfElem();

                   Virtual string GetAttrib(const string& strName) const;

                   Virtual string GetChildAttrib(const string& strName) const;

            };

             

            Class CTinyXMLParser: public IXMLParser

            {

                  

            };

             

            可以看到通過這種方式,我們把XML的解析過程抽象出來,我們本身不用關心解析器的類型(說明:上面XML解析的設計不一定合理,只是一個示例)

             

            現在我們可以開始寫我們的Control Tree Builder了,

            Class CControlBuilder:

            {

                   Public:

                          CControlBase* BuildControlTree(const string& strXML)

                          {

                                 CTinyXMLParser parser;

                                 parser.SetDoc(strXML);

                                 CControlFactory* pFactory = CControlFactory::Instance();

                                

                                 String strControl = parser.GetTagName();

                                 CControlBase* pRoot = pFactory->CreateContorl(strControl);

                                 ….

             

                                 Return pRoot;

            }

            };

             

            顯然上面的方式, 我們修改XML解析器的類型很不方便,我們可以通過工廠方法(Factory Method)來方便以后擴展。

             

             

            Class CControlBuilder

            {

                   Public:

                          CControlBase* BuildControlTree(const string& strXML)

                          {

                                 Auto_ptr< IXMLParser > parser = CreateXMLParser() ;

                                 Parser->SetDoc(strXML);

                                 CControlFactory* pFactory = CControlFactory::Instance();

                                

                                 String strControl = parser->GetTagName();

                                 CControlBase* pRoot = pFactory->CreateContorl(strControl);

                                 ….

             

                                 Return pRoot;

            }

             

            Protected:

            Virtual IXMLParser* CreateXMLParser()

            {

                   Return new CTinyXMLParser;

            }

            };

             

            好了,到這里我們所有的設計都全部完成了,基本類圖如下:

            PS, 在設計CControlBuilder時,本來考慮是不是該用設計模式中的生成器(builder)模式, 但是Builder模式強調的是同樣的創建過程,生成不同的產品。顯然我們這里無論XML如何解析,最終只有Root Control這一種產品。 所以這里如果用這個模式的話,就有點過度設計了。

             

            總結一下,我們上面用了哪些設計模式?
            Composite, Abstract Factory, Factory Method, Singleton, Prototype.
            你看出來了嗎?
            你們有更好的設計思路嗎?

             說明: (1)上面的代碼都只是設計時的偽代碼,拿來編譯肯定過不了
                    (2)考慮Windows的窗口類注冊和創建機制,會發現盡管WindowsAPIC語言方式,但是設計思想是類似的。
                    (3) 對于DirectUI來說,上面控件類的這種層次設計其實很濫, 有興趣的話可以學下WPFJ

             

             

            posted on 2012-06-10 17:31 Richard Wei 閱讀(4542) 評論(4)  編輯 收藏 引用 所屬分類: 設計模式

            FeedBack:
            # re: 生成DirectUI 控件樹的設計過程
            2012-06-11 16:38 | 飯中淹
            我覺得有幾個問題
            1- UI依賴了XML。因為你如果要改變數據源,你需要改變UI內部的東西。
            我做的系統里,用了抽象的DOM數據NODE的概念。XML只是建立數據NODE的一個源而已。

            2- UI的創建很多都用不到。比如prototype這種,如果你想讓你的UI從數據上創建,那么你就用一個從數據創建就好了。

            我的系統里,UI控件的CREATE都是只有統一的一個參數,IDataNode。這樣接口非常簡單。

              回復  更多評論
              
            # re: 生成DirectUI 控件樹的設計過程
            2012-06-11 18:12 | Richard Wei
            @飯中淹

            沒太看明白你說的問題, 但是我想對于UI來說很多東西是類似的,
            就一個UI(窗口)本身是一棵遞歸的樹,內部有容器和控件,相當于樹的分支(node)和樹葉(leaf),并且可以無限遞歸, 這個層次很符合Composite模式,也很符合用XML來描述。

            所以現在比較流行的UI框架(比如WPF, WEB頁面)都分2層來描述,一層是標記(markup). 比如WPF里的XAML, Web頁面里的HTML; 另外一層是代碼(code), 比如WPF里用C#, Web頁面里用javascript.

            其實本質上code部分才是真正的實現,內部定義了所有的控件層次, 所以即使不依賴markup部分,我們同樣可以定義和操作所有的UI, 但是借助Markup可以讓我們更方便的生成和修改UI。

            至于用不用Prototype模式不太重要,我這里的想法是讓控件有默認的風格屬性,而且這個默認風格屬性也是容易修改的。通過用Prototype,我可以在XML里定義默認的控件原型,程序初始化時用該原型來注冊控件就可以了。另外, 如果有些控件你覺得用不到,不去注冊就好了。 這種注冊機制, 對于支持插件(控件)也很方便,你覺得呢?  回復  更多評論
              
            # re: 生成DirectUI 控件樹的設計過程
            2012-06-12 14:09 | 飯中淹
            。。。。并不是說用XML不好,或者否定UI樹什么的。

            我也是用的MARKUP來建立UI控件樹,并綁定代碼。不過,我是用了一個中間的DOM抽象數據層。
            這樣,不管外面有什么XML,HTML甚至INI,我只要一個數據抽象層放進UI里面就好了。





            @Richard Wei
              回復  更多評論
              
            # re: 生成DirectUI 控件樹的設計過程
            2012-06-26 15:46 | 叫我老王吧
            最近也在寫UI,受益匪淺,受教了  回復  更多評論
              
            99麻豆久久久国产精品免费| 一本久久免费视频| 久久精品国产亚洲av麻豆小说| 亚洲人成伊人成综合网久久久| 久久亚洲国产成人精品性色| 国产精品免费久久久久电影网| 亚洲午夜无码久久久久小说| 久久婷婷国产综合精品| 国内精品久久久久久久涩爱| 女人高潮久久久叫人喷水| 久久本道伊人久久| 精品多毛少妇人妻AV免费久久| 成人免费网站久久久| 久久久久久曰本AV免费免费| 国产精品久久久99| 国产精品久久精品| 中文字幕无码精品亚洲资源网久久| 久久精品嫩草影院| 久久99国产综合精品| 精品久久久久久久国产潘金莲| 亚洲国产二区三区久久| 久久精品中文闷骚内射| 狠狠色丁香久久婷婷综合_中| 国产福利电影一区二区三区久久老子无码午夜伦不 | 久久久精品波多野结衣| 国产亚洲综合久久系列| 国内精品综合久久久40p| 欧美日韩成人精品久久久免费看 | 九九精品久久久久久噜噜| 久久国产精品久久国产精品| 日产精品久久久一区二区| 久久亚洲国产精品成人AV秋霞| 久久久久亚洲精品无码网址 | 久久九九久精品国产免费直播| 久久久WWW成人| 欧美激情精品久久久久久久 | 精品久久久久久久无码| 日产精品久久久久久久| 久久久久99精品成人片欧美| 伊人久久精品无码二区麻豆| 久久综合九色综合网站|