乌托邦式接口和实现分离技术
可以这么做：
typedef Reform ＜
利用Combine,我们可以充分发挥多重继承的组合能力，我们既享受了接口设计和实现分离的好处—更容易维护概念了，也充分享有代码复用的能力。并且，将设计决策充分推迟：甚至客户程序员完全可以定制自己的接口实现从而和现有系统结合，这是一个完美的Open-Close的设计手段。 ＜!--[if !supportLists]--＞＜!--[if !supportLists]--＞＜!--[if !supportLists]--＞＜!--[if !supportLists]--＞ 现在，总结一下在多重继承中的注意事项。 1．接口尽量是单继承的。 2．多重继承的接口必须意识到，所有继承树的相同接口只能共享同一份实现。 3．严苛地去维护接口的概念，不要为了实现问题定义中间的接口（就象那个IFileHttpReader） 4．合理地利用多重继承的组合能力。＜!--[if !supportEmptyParas]--＞ 关于最后一条，您可以做一些有趣的探索。给出一个空基类: struct Over{};
当然，也可以是其它非模板类。把所有的类都实现成模版形式：ImpClassA＜T＞, ImpClassB＜T＞,借助于Combine,我们可能给出这样的定义： typedef Combine＜ImpClassA＜ Combine＜ImpClassB＜ Over ＞, ImpClassC＜ Over ＞ ＞ ＞,Combine＜ImpClassF＜Over＞, ImpClassB＜ImpClassD＜ Over ＞ ＞＞,ImpClassE＜Over＞＞::type ConcreteSomeClass; 我们注重于将这些ImpClasses拆成尽可能小的正交模块。那么借助组合技术，可能获得很高的复用性。但是，有句老话，不要为了复用而复用，反正，这里的探索我也是浅尝辄止，出了什么事情和我无关。特别提醒一下，上面代码中Combine里面出现了一个type,你可以尝试在上面施加你喜欢的TMP手法嘛。 把那些有趣的探索先放在一边。现在，我已经把这种技术完整地呈现出来了。然而，没有一项技术是完美的，这里也不例外。这个技术有两个小小的缺陷。 第一个缺陷则是构造函数的问题。回顾Combine的实现，我们无法为Combine额外提供合适的构造函数。不过，这个问题并不是特别严重，我们完全可以定制自己的Combine。并且，这些不同的Combine可以混合使用。另外，在组装的时候需要小心的维护构造函数的调用链，这可能伤害到复用性。Assignment中也存在类似的问题。运算符重载也可能导致混乱，不过，我一直认为，在值语义之外的类当中重载运算符可是要非常谨慎的，很显然，我们这里展示的技术并不适合值语义的类型设计。 另一个缺陷是工程上的。因为上述的实现都是模板类，所以，我们通常需要将实现在头文件里面提供，这个可能是有些人不愿意的。我将展现一种解决的方法，这就是另一个利器：Pimpl惯用法。 以IReader为例，假设如下接口： struct IReader : IRefCount
现在，我们只实现read方法： class ConcreteImpReader;//前置申明
现在，给出一个原始的Pimpl实现： template＜typename T＞
在单独的文件中实现： class ConcreteImpReader |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
