有同事很喜歡用Context模式，覺得是自己"首創(chuàng)", 我有些自己的想法， 或者大家可以發(fā)表下自己的觀點。
什么是Context模式？
23種設(shè)計模式中沒有這個模式， 是同事自己命名的， 我覺得名字也挺合理。
Context模式首先要滿足的條件是類都是基于COM思想IUnknown接口
繼承于IUnknown有2個基本接口， 一個是IContext， 另外一個是IComponent
IContext的作用是保存一個Map， 里面存有接口IID和接口指針的映射關(guān)系
IComponent的作用是保存一份對IContext的引用， 通過IContext它可以查詢到任何保存在里面的接口
任何比較" 大型“的接口和對象都從IComponent繼承，并在對象初始化時把自己存入IContext，
這種設(shè)計的好處就是我們在實現(xiàn)對象時可以查詢到任何我們需要的接口。
大概類圖如下：
上面的設(shè)計好處很明顯， 就是使用簡單， 任何接口我們都可以查詢到， 我們在寫程序時應(yīng)該有這樣的體驗， 往往需要一個全局的CXXXApp對象實例， 然后我們可以通過這個對象實例， 一層層往下查詢到其他的對象和接口， MFC就是這么做的。如果我們用上面這個模式， 我們就不需要依賴于某個全局對象了， 因為我們繼承的IComponent接口本身就有查詢其他對象的能力了。
但這樣的設(shè)計也有一些缺陷：
首先是多實例支持不了了， 因為我們根據(jù)接口ID來查詢某個對象指針，一個接口實現(xiàn)類的多個實例沒法存到IContext中； 多個類可以實現(xiàn)同一接口， 這些類實例對象也沒法存儲多個。COM里面除了IID， 還有CLSID來標志實現(xiàn)類。
其次是耦合性， 盡管耦合是基于接口耦合， 依賴性已經(jīng)降到最低，但是還是在原本不需要耦合的地方產(chǎn)生了耦合， 把別人用不到接口暴露給他了。
最后是復雜性， 因為IContext里什么都可以查詢到， 所以我們會在不經(jīng)意間什么都向它要， 將原本設(shè)計時的單向依賴變成雙向依賴， 最后演變成復雜的網(wǎng)狀依賴， 最后對代碼徹底失去控制
究竟什么時候該用這個模式？ 我個人的建議是在小模塊內(nèi)部使用。
模塊劃分首先強調(diào)層次性， 就是 單向依賴， 上層依賴于下層， 積木式的層層堆砌。如果在模塊間傳遞Context指針， 很快會變成網(wǎng)狀依賴， 對程序失去控制， 誰知道別人拿了你這個IContext指針查詢了那些接口， 最后干嘛去了。
大模塊內(nèi)部，除非模塊內(nèi)部層次很清楚， 你能很好的控制。一般我們也不建議使用Context模式， 因為不知不覺就會造成復雜的網(wǎng)狀依賴，會對程序就會失去控制。
對于對象和接口間的依賴，不知道大家是怎么解決的？ 我想大部分人應(yīng)該是通過全局對象或是顯式的傳遞需要的接口指針來做的。
對于Context模式，大家怎么看？
posted on 2013-11-22 23:29
Richard Wei 閱讀(5418)
評論(2) 編輯 收藏 引用 所屬分類:
設(shè)計模式