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