青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

在寫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 閱讀(4585) 評論(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,受益匪淺,受教了  回復  更多評論
  
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            国产精品久久久对白| 国产欧美婷婷中文| 亚洲区一区二| 久久国产精彩视频| 亚洲欧美精品一区| 午夜精品久久久久久久99热浪潮| 99国产精品久久久久久久久久| 亚洲国产色一区| 亚洲精品中文字幕在线| 亚洲欧洲偷拍精品| 99视频一区二区| 亚洲一区精品视频| 欧美成人一区在线| 亚洲日本中文字幕免费在线不卡| 亚洲欧洲一区二区在线观看| 99在线观看免费视频精品观看| 日韩午夜高潮| 欧美一区激情| 国产精品高清网站| 亚洲国产精品一区二区第一页| 另类综合日韩欧美亚洲| 欧美国产精品va在线观看| 99热免费精品在线观看| 性久久久久久久| 欧美jjzz| 国产视频精品xxxx| 亚洲日本理论电影| 欧美中文字幕视频在线观看| 牛牛国产精品| 亚洲一区精品视频| 欧美mv日韩mv国产网站| 韩国av一区二区三区在线观看| 亚洲麻豆av| 久久久女女女女999久久| 日韩午夜电影| 欧美成人精品影院| 国产性色一区二区| 亚洲免费伊人电影在线观看av| 久久综合久久久久88| 中文日韩电影网站| 欧美激情综合在线| 1769国产精品| 欧美一区二区三区免费视| 亚洲欧洲一区二区三区| 久久精品视频免费播放| 久久嫩草精品久久久精品| 国产一区二区三区四区三区四| 亚洲久色影视| 欧美黑人在线播放| 久久久另类综合| 国产在线高清精品| 久久精品国产一区二区三区免费看| 亚洲免费黄色| 欧美成人资源网| 亚洲精品色婷婷福利天堂| 牛牛国产精品| 免费在线观看成人av| 樱桃视频在线观看一区| 久久久综合免费视频| 久久9热精品视频| 国产亚洲精品综合一区91| 亚洲男女毛片无遮挡| 亚洲精品乱码久久久久久日本蜜臀 | 久久精品国产亚洲a| 欧美一区深夜视频| 中文av字幕一区| 欧美精品久久久久久| 欧美中在线观看| 国产精品99久久不卡二区| 牛牛精品成人免费视频| 久久免费精品视频| 国产亚洲欧洲| 欧美一区日本一区韩国一区| 亚洲欧美一区在线| 国内成+人亚洲| 久久亚洲高清| 久久午夜av| 亚洲人屁股眼子交8| 亚洲国产美女| 欧美四级在线观看| 欧美亚洲在线播放| 久久aⅴ国产紧身牛仔裤| 亚洲国产精品一区二区www| 亚洲国产精品精华液2区45| 欧美另类人妖| 欧美一区二区三区四区在线观看| 欧美一级专区| 亚洲日本久久| 午夜视频一区二区| 亚洲国产清纯| 99精品视频免费| 国产精品网曝门| 欧美大片在线观看| 欧美日韩中文字幕在线| 欧美在线999| 免费欧美视频| 亚洲欧美日韩在线综合| 欧美大片一区二区三区| 国产精品一二一区| 欧美多人爱爱视频网站| 欧美午夜免费影院| 久久在线精品| 欧美日韩精品在线视频| 久久婷婷麻豆| 欧美视频在线免费看| 久久夜色精品国产| 欧美视频二区| 欧美mv日韩mv国产网站| 国产精品夜色7777狼人| 亚洲国产片色| 黄色成人av在线| 亚洲视频一区在线| 亚洲人成网站色ww在线| 午夜久久久久久久久久一区二区| 亚洲片在线观看| 久久精品日韩| 久久精品国产亚洲a| 国产精品欧美日韩一区| 91久久精品美女| 国内外成人免费激情在线视频| 亚洲巨乳在线| 日韩亚洲欧美成人一区| 久久久亚洲影院你懂的| 久久国产精品久久精品国产| 欧美三级视频在线播放| 亚洲福利视频网站| 在线亚洲国产精品网站| 欧美国产国产综合| 久久久www成人免费无遮挡大片| 久久精品国产96久久久香蕉| 亚洲综合精品四区| 欧美日韩国产综合视频在线观看| 欧美第十八页| 在线欧美一区| 久久精品国产免费观看| 久久精品网址| 国产一区二区久久| 欧美一级艳片视频免费观看| 欧美尤物一区| 国产一区二区三区在线观看网站| 亚洲一区日韩在线| 篠田优中文在线播放第一区| 欧美三区美女| 99国内精品久久| 亚洲欧美日本国产有色| 欧美三级中文字幕在线观看| 亚洲天堂第二页| 亚洲在线中文字幕| 欧美日韩午夜精品| 亚洲私人黄色宅男| 久久国产精品99久久久久久老狼| 国产亚洲成年网址在线观看| 久久riav二区三区| 欧美成年人视频网站欧美| 最新高清无码专区| 你懂的视频一区二区| 亚洲精品中文字幕在线| 午夜久久美女| 国产一区二区高清不卡| 久久综合久久综合九色| 欧美激情第二页| 亚洲午夜精品一区二区三区他趣| 久久综合精品国产一区二区三区| 亚洲精品三级| 欧美一区二区三区视频在线| 影音先锋日韩精品| 欧美日本韩国| 亚洲欧美日韩国产综合精品二区| 久久精品午夜| 亚洲精品一区二区三区福利| 国产精品mv在线观看| 欧美在线看片| 亚洲免费av电影| 久久久久网址| 99这里只有精品| 国产午夜精品久久久| 免费91麻豆精品国产自产在线观看| 亚洲日本中文字幕区| 亚洲欧美另类久久久精品2019| 国产一区二区精品丝袜| 欧美日韩国产三区| 久久久久久色| 亚洲欧美卡通另类91av| 欧美激情aⅴ一区二区三区| 亚洲手机视频| 亚洲成人原创| 国产一区二区三区的电影| 欧美黑人在线观看| 久久黄色网页| 亚洲综合欧美日韩| 亚洲美女福利视频网站| 麻豆精品91| 久久国产精品高清| 亚洲在线免费观看| 亚洲免费观看在线观看| 永久久久久久| 国产在线欧美日韩| 久久乐国产精品| 夜夜爽av福利精品导航| 国产精品免费久久久久久|