乌托邦式接口和实现分离技术
| 忠告吗--“不要在虚基类中存放数据成员”。“这样有什么问题吗，我们不必对大师盲目崇拜”，你一定也听过这样的建议。如果大师们不能说服这些人，那么我也不能。于是，我们进一步在所有的接口中提供默认实现，包括IReader和IWriter. 现在的问题是: struct IRWiter : IReader, IWriter;
还是 struct IRWiter : virtual IReader, virtual IWriter ?
如果你没有选择virtual，那么IRWiter被派生后，那么派生类的继承树中可能存在多个IReader实现，如果这个派生类要求只能提供一份IReader的语义怎么办？除了重新实现接口还能怎样？反过来，如果我们选择了virtual继承，那么派生类需要多个实现怎么办？真是个麻烦事。“这是典型的过度设计，我们为什么要考虑这么多？”你可以这么说，但事实上，即使是一个数百文件的小型系统，也完全可能迫使你作出选择。虽然，我们仍然有办法作出挽救措施，但是也只是苟延残喘而已。正如我前面所说，这是一个危险的道路，聪明如你，是断然不会让自己陷入这样的泥潭的。 让我们离开虚拟继承，先回到重复代码的问题上来。有没有更好的解决办法呢？还好，在C++的世界里，我们有神奇的template,让我们来消除重复的代码： template＜typename Base＞
请注意，我们还是假设IRefCount已经提供了一个默认实现。现在，情况好了很多，所有的代码都只有一份，而且，概念也没有被破坏。假设，Writer也同样需要类似的能力，那么，我们又多了StackWriter和HeapWriter.事实上，真的有人用到了StackWriter吗？我不知道，只是，提供了StackReader，没有理由不提供StackWriter啊。让我们继续。 现在，我们发现，需要改进内存分配的性能问题,于是，我们希望通过内存池来分配对象，相应的dispose也需要修改： virtual void dispose(){ distory(this);}
于是，我们又多出两个类，PoolReader和PoolWriter。这真是糟糕，组合爆炸可不是什么好兆头。 从我们前述的变化来看，都是IRefCount在变化，为什么不把这种变化分离出来呢？不必为IRefCount提供默认实现，借鉴ImpReader的手法： template＜typename Base＞
类似的: template＜typename Base＞ class ImpStackRefCount : public Base;
再看看，我们如何实现所有的Reader. typedef ImpReader＜ ImpHeapRefCount＜IReader＞ ＞ HeapReader;
以HeapReader为例，实际的继承关系是这样的： ImpReaderàImpHeapRefCountàIReaderàIRefCount;
对于Writer,我们完全可以采取同样的手法来实现。对于上述的typedef可以预先定义，也完全可以不定义，交给最终用户去组装吧。现在，类的设计者再也不必为选择实现而痛苦了，你只要提供不同的砖头，客户程序员可以轻而易举的建立起大厦。还有比这更让一个设计师幸福的吗？ 继续深入，考察ImpHeapRefCount和ImpStackRefCount的实现，我们提到，dispose方法的实现是不一样的，但是，其他部分：add,releasee和count的实现完全可以相同。然而我们现在又 |
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
