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

在寫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方法,不符合面向對象設計的開放封閉原則(OCP,Open 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 閱讀(4598) 評論(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| 亚洲欧美日韩一区在线| 亚洲人成在线观看网站高清| 久久久久久9| 国产一区二区久久| 欧美在线一二三四区| 亚洲一区二区影院| 国产精品劲爆视频| 亚洲欧美国产另类| 亚洲深夜激情| 国产精品av久久久久久麻豆网| 99精品福利视频| 亚洲欧洲在线视频| 欧美激情中文字幕在线| 亚洲国产婷婷香蕉久久久久久99| 欧美大片免费观看| 欧美精品久久99久久在免费线| 亚洲乱码视频| 亚洲美女淫视频| 国产精品久久77777| 亚洲一区精品电影| 亚洲免费视频网站| 国产综合激情| 欧美激情一区在线观看| 欧美精品久久久久久久久老牛影院| 亚洲精品精选| 日韩图片一区| 国产毛片精品国产一区二区三区| 久久国产婷婷国产香蕉| 在线观看成人小视频| 在线欧美福利| 亚洲国内在线| 另类亚洲自拍| 亚洲精品欧美在线| 小处雏高清一区二区三区| 国产性天天综合网| 免费在线成人av| 欧美精品三级在线观看| 午夜欧美电影在线观看| 久久免费国产精品1| 亚洲三级毛片| 亚洲午夜久久久久久久久电影网| 国内精品写真在线观看| 亚洲高清视频一区二区| 亚洲精品网站在线播放gif| 国产精品影音先锋| 亚洲欧洲美洲综合色网| 国产日韩精品视频一区二区三区 | 一区二区三区.www| 午夜日本精品| 亚洲美女少妇无套啪啪呻吟| 欧美一级片一区| 亚洲国产专区| 亚洲欧美日韩国产综合| 亚洲七七久久综合桃花剧情介绍| 亚洲午夜久久久| 亚洲人午夜精品免费| 午夜在线一区二区| 亚洲天堂免费观看| 免费在线看一区| 久久aⅴ乱码一区二区三区| 欧美精品一区在线| 免费成人黄色| 国产精品亚洲一区| 亚洲免费观看| 亚洲欧洲精品一区二区三区| 欧美一区二区三区免费观看视频 | 在线亚洲成人| 欧美v日韩v国产v| 久久久国产精品一区二区三区| 欧美日韩精品一区| 亚洲福利视频网站| 尤物九九久久国产精品的特点| 亚洲素人一区二区| 亚洲一级在线观看| 欧美日韩精品在线| 亚洲欧洲视频| 亚洲三级电影在线观看 | 在线观看视频一区| 性欧美大战久久久久久久免费观看| 一本在线高清不卡dvd| 久久综合久久综合久久综合| 亚洲欧美日韩在线不卡| 国产精品高精视频免费| 99热在这里有精品免费| 在线亚洲伦理| 欧美三区免费完整视频在线观看| 亚洲激情成人网| 99热在线精品观看| 欧美一区二区三区免费视| 欧美电影在线观看完整版| 国产综合香蕉五月婷在线| 欧美亚洲视频在线观看| 欧美日韩三级| 中日韩美女免费视频网址在线观看| 在线视频精品一| 欧美亚男人的天堂| 亚洲一区在线视频| 欧美在线黄色| 怡红院精品视频| 蜜臀av在线播放一区二区三区| 亚洲高清视频一区二区| 9色精品在线| 国产精品日韩久久久| 午夜精品一区二区三区四区| 久久性天堂网| 亚洲老司机av| 欧美日韩成人在线观看| 在线亚洲一区二区| 久久久成人网| 日韩视频免费观看| 国产精品你懂的在线欣赏| 性伦欧美刺激片在线观看| 久久综合给合| 99国产精品99久久久久久| 国产精品麻豆成人av电影艾秋| 午夜精品av| 欧美激情一区二区三区蜜桃视频| 中国成人黄色视屏| 国产一区二区在线观看免费| 欧美国产三级| 欧美一级大片在线免费观看| 欧美激情片在线观看| 亚洲先锋成人| 激情综合视频| 欧美日韩喷水| 久久精品二区亚洲w码| 亚洲另类在线一区| 久久资源av| 亚洲欧美综合精品久久成人| 亚洲国产精品久久久久婷婷老年 | 国产毛片一区二区| 欧美电影免费观看高清| 性感少妇一区| 亚洲毛片在线观看| 美女图片一区二区| 亚洲男人的天堂在线aⅴ视频| 精久久久久久久久久久| 国产精品美女午夜av| 欧美.www| 久久成人国产精品| 中文国产一区| 亚洲国产精品va| 欧美午夜精品久久久久免费视 | 亚洲一级黄色av| 亚洲黄色片网站| 久久综合狠狠综合久久激情| 亚洲愉拍自拍另类高清精品| 亚洲国产日韩美| 国产一区二区久久久| 欧美视频在线观看免费| 欧美黄色成人网| 久久伊人亚洲| 欧美一区二区三区四区在线观看 | 欧美在线日韩精品| 欧美激情精品久久久久久蜜臀| 亚洲女女女同性video| 亚洲精品国产拍免费91在线| 免费成人在线观看视频| 欧美一区二区福利在线| 一本色道婷婷久久欧美| 91久久午夜| 亚洲福利视频网| 禁久久精品乱码| 国内揄拍国内精品久久| 国产日韩欧美精品综合| 国产精品亚洲综合天堂夜夜 | 亚洲麻豆视频| 亚洲国产日韩欧美在线99| 狠狠综合久久| 国内一区二区三区| 国产一区二区丝袜高跟鞋图片| 国产精品一二一区| 国产精品女主播一区二区三区| 欧美特黄视频| 国产精品区一区| 国产精品日韩欧美| 国产美女精品免费电影| 国产日韩在线视频| 韩国福利一区| 亚洲高清在线观看一区| 亚洲激情成人| 99国产精品久久久久久久成人热 | 亚洲欧美成人综合| 午夜激情一区| 久久精品视频va| 老司机67194精品线观看| 久久综合中文| 欧美激情第一页xxx| 欧美日韩极品在线观看一区| 欧美亚男人的天堂| 国产日韩欧美91| 亚洲电影在线免费观看| 久久天天躁狠狠躁夜夜爽蜜月 | 亚洲精品中文字幕在线| 99re国产精品| 先锋资源久久|