有同事很喜欢用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 阅读(5375)
评论(2) 编辑 收藏 引用 所属分类:
设计模式