• <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>
            有同事很喜歡用Context模式,覺得是自己"首創", 我有些自己的想法, 或者大家可以發表下自己的觀點。

            什么是Context模式?

            23種設計模式中沒有這個模式, 是同事自己命名的, 我覺得名字也挺合理。

            Context模式首先要滿足的條件是類都是基于COM思想IUnknown接口
            繼承于IUnknown有2個基本接口, 一個是IContext, 另外一個是IComponent
            IContext的作用是保存一個Map, 里面存有接口IID和接口指針的映射關系
            IComponent的作用是保存一份對IContext的引用, 通過IContext它可以查詢到任何保存在里面的接口
            任何比較" 大型“的接口和對象都從IComponent繼承,并在對象初始化時把自己存入IContext,
            這種設計的好處就是我們在實現對象時可以查詢到任何我們需要的接口。

            大概類圖如下:





            上面的設計好處很明顯, 就是使用簡單, 任何接口我們都可以查詢到, 我們在寫程序時應該有這樣的體驗, 往往需要一個全局的CXXXApp對象實例, 然后我們可以通過這個對象實例, 一層層往下查詢到其他的對象和接口, MFC就是這么做的。如果我們用上面這個模式, 我們就不需要依賴于某個全局對象了, 因為我們繼承的IComponent接口本身就有查詢其他對象的能力了。

            但這樣的設計也有一些缺陷:

            首先是多實例支持不了了, 因為我們根據接口ID來查詢某個對象指針,一個接口實現類的多個實例沒法存到IContext中; 多個類可以實現同一接口, 這些類實例對象也沒法存儲多個。COM里面除了IID, 還有CLSID來標志實現類。

            其次是耦合性, 盡管耦合是基于接口耦合, 依賴性已經降到最低,但是還是在原本不需要耦合的地方產生了耦合, 把別人用不到接口暴露給他了。
            最后是復雜性, 因為IContext里什么都可以查詢到, 所以我們會在不經意間什么都向它要, 將原本設計時的單向依賴變成雙向依賴, 最后演變成復雜的網狀依賴, 最后對代碼徹底失去控制

            究竟什么時候該用這個模式? 我個人的建議是在小模塊內部使用。

            模塊劃分首先強調層次性, 就是 單向依賴, 上層依賴于下層, 積木式的層層堆砌。如果在模塊間傳遞Context指針, 很快會變成網狀依賴, 對程序失去控制, 誰知道別人拿了你這個IContext指針查詢了那些接口, 最后干嘛去了。

            大模塊內部,除非模塊內部層次很清楚, 你能很好的控制。一般我們也不建議使用Context模式, 因為不知不覺就會造成復雜的網狀依賴,會對程序就會失去控制。

            對于對象和接口間的依賴,不知道大家是怎么解決的? 我想大部分人應該是通過全局對象或是顯式的傳遞需要的接口指針來做的。
            對于Context模式,大家怎么看?
            posted on 2013-11-22 23:29 Richard Wei 閱讀(5466) 評論(2)  編輯 收藏 引用 所屬分類: 設計模式

            FeedBack:
            # re: 關于 "Context" 模式
            2013-11-23 08:58 | 萬連文
            IServiceProvider->IService->IComponent

            小模塊更明確直接使用最終的組件,大模塊需要能拿到全局的IServiceProvider以便調用需要的服務??傊枰獧嗪?,度的拿捏是架構關鍵。  回復  更多評論
              
            # re: 關于 "Context" 模式
            2013-11-23 14:11 | Richard Wei
            @萬連文
            嗯,確實度是關鍵, 實際上怎樣才算一個模塊? 它的粒度可以是個小的靜態Library, 也可能是個龐大的Service。最關鍵的就是要保持模塊的獨立性和層次性,避免形成網狀依賴。
              回復  更多評論
              
            99精品久久久久中文字幕| 99久久综合狠狠综合久久| 国产免费久久精品99re丫y| 区久久AAA片69亚洲| 国产99精品久久| 亚洲国产精品无码久久久久久曰 | 久久久亚洲精品蜜桃臀| 国内精品伊人久久久影院| 久久99国产精品二区不卡| 一本色道久久88综合日韩精品 | 久久综合久久鬼色| 狠狠干狠狠久久| 亚洲av成人无码久久精品| 99久久国产热无码精品免费久久久久 | 少妇内射兰兰久久| 国产精品一区二区久久精品无码 | 久久人妻少妇嫩草AV无码蜜桃| 亚洲国产精品无码久久久秋霞2| 国产精品日韩欧美久久综合| 精品久久久久久久无码 | 精品多毛少妇人妻AV免费久久| 91精品日韩人妻无码久久不卡| 久久综合综合久久综合| 久久国产欧美日韩精品| 久久精品国产男包| 午夜肉伦伦影院久久精品免费看国产一区二区三区 | 18岁日韩内射颜射午夜久久成人| 久久天天躁狠狠躁夜夜不卡| 人人狠狠综合久久亚洲婷婷| AV狠狠色丁香婷婷综合久久| 久久精品国产亚洲av麻豆蜜芽| 久久人人添人人爽添人人片牛牛| 久久天天日天天操综合伊人av| 国产午夜电影久久| 97久久精品人人做人人爽| 久久AⅤ人妻少妇嫩草影院| 99久久精品国产麻豆| 日韩亚洲欧美久久久www综合网| 久久免费国产精品一区二区| 久久精品一区二区三区不卡| 91精品日韩人妻无码久久不卡 |