乌托邦式接口和实现分离技术

然后，我们可以这样定义Reader：

请注意，我们在这里展示了一种能力，不必在一个实现当中完整的实现整个接口，可以把一个接口的实现分拆到多个实现当中。这个能力是非凡的，借助于此，我们可以提供更小粒度的实现单位，给最终用户来组装。具体拆分到什么样的程度完全取决于代码复用的需求，以及概念维护的需要。

我们提供了高度的复用能力，同时避免了继承带来的强耦合，以及对推迟设计决策的支持，这些能力对于软件设计师而言，正如Matthew在《Imperfect C++》中所说的，这简直就是现实中的乌托邦！

现在我们把这种手法首先针对单继承做一个小结。对于任意的接口IInterface,我们提供如下的实现:

请注意，一个接口可以有任意多个实现，并且可以是任意的部分实现。＜!--[if !supportEmptyParas]--＞ ＜!--[endif]--＞

假设我们有如下接口继承树：

并且提供了实现类ImpInterface0 ~ ImpInterfaceN.

那么，InterfaceN的实例类型就是:

我们注意到，定义ConcreteClassN的时候，我们的ImpInterface是按照顺序来的，我认为这是合适的做法。当然了，最后组装的权力已经交给客户了，客户爱怎么组装就怎么组装吧。然而我们还是有一些需要注意的问题。

1．假定，我需要在ImpInterfaceI中引用基类的方法，记住，不要使用这样的手法：

这样调用不具有多态性，而应该这样：

2．不要在自己的ImpInterfaceI实现中覆盖基类接口的其他已经实现的方法，如果你一定要这么做，那么务必在文档中说明，因为在组装的时候，顺序将是极其关键的了。

3．这个方法和设计模式中的Template Pattern目的是不一样的。Template Pattern是在基类中定义了一个算法，让派生类定制算法的某些步骤。这里的方法针对的是接口模型的概念，提供接口和实现分离的技术。

关于第二条，应该尽量避免发生。这里说的覆盖是指基类实现已经实现了该方法，而后继实现又覆盖该方法。基类实现可以是一个部分实现，对于没有实现的那些方法，在派生接口的实现类中实现则是常见的。一方面，我们尽量合理分解层次之间的功能，另一个方面，可以通过定制实现模板类，来保证顺序。尽可能的让语言本身来保证正确性，而不是依赖文档。我们可以像这样预先装配一些东西：

可惜，C++暂时还不支持模板的不完全typedef，否则，我们还可以如下定以：

不过，C0x很可能会支持类似的语法。这样，我们使用SomeComponent来作为一个预制品，来保证一些安全性，而不必完全依赖文档了。 ＜!--[endif]--＞

看看ConcreteClassN的定义，也许你和我一样，并不喜欢这种嵌套的、递归的

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!