看了上一篇之后：
我很好奇，想请教你如何在运行期实现把ShoppingItem接口
加入到Book的接口中？
如你所说，这才是这个问题的重点，也是分歧的重点。
其他的实现都受制于这个。

跟人详细讨论你发的文章的语言逻辑之后，加上部分揣测，
我替你把你的想法清楚明确的说出来，你看看对不对：

一.你所说的“动态接口模式”有如下几个概念：
1，动态接口：
你所谓的动态接口，还是要自己写.java代码然后编译成class文件的
问题的关键在于，你的每一个动态接口都有一个具体实现类：

如上图所示

2, BookManager类：
你的getBook方法大概会定义成为getBook(DyInterface di){...}在你的类图里并没有为这些动态接口定义一个统一的接口，为了更动态的使用这个getBook方法，建议实现定义一个标记接口BookAction，每个动态接口都继承这个标记接口.这样BookMananger的方法就可以明确定义为getBook（BookAction bookAction）而不是getBook(...)

3， BookImpl类
在此方法里，我猜你用反射之类的机制，获取动态接口的实现类类名和方法名。
有了这些，你就可以不用改变BookImpl类的代码了。

不知道我分析的对不对，但是根据你的几篇答复，我只能在逻辑上如此推论，才能觉得比较完满。
如果真如上所示那么请看下面一段，如果以上内容我说错了，请跳过下面一段，如果不小心看下去，而且你有哪怕一点点气愤的话，那么请接收我诚挚的歉意。

恕我直言，我比较的后悔，一直跟着你的思路走（你的帖子加上我自己的理解）。原因如下：
1，你的类图画的一点儿也不好，确切的说有待好好学习如何用类图来表达自己的想法。误导了几乎所有人，也浪费了我的时间，你所谓的动态接口，最最要控诉的是BookImpl那些动态的接口根本没有直接的实现关系（也即你第一个类图里所画的那样），BookImpl只是使用了它们罢了。

2，你在发表自己想法的时候，前后矛盾的地方很多，逻辑有点混乱，建议以后发文章自己先整理整理，前言不答后语的别人看着费劲，更对不起那些支持你帖子的道友们

除此之外，对你表示感谢，因为你这个帖子，我好好的体会了一下装饰模式的使用，适配器模式的使用，虽然不怎么成功，但是对他们的使用有一定的体会，毕竟才刚学不久。而且也预习了一下Visitor模式，经过预习，我发现在某些场合下它比我的其他想法要好多了。

在这个讨论过程中，我还明白了，是先有需求，后有模式。而不是先造模式，后
看它可以在哪里用的。以此作为我在这场讨论中的结语。

很好，我想批评才会带来进步。
也许我应该将下面的类图作为讨论的开始，这样可能会比较容易理解。

我之所以将动态接口对象作为一种设计模式提出，而非当作一种编程技巧，是因为该模式具有普遍意义。
实现本身并不十分重要（虽然它常常影响设计），因此使用反映机制也好，或使用动态代理机制也好，或使用类增强器也好，甚至直接使用上图的设计也好，这些并不是重点。重要的是设计思想，即我想讨论的重点是：我们是否可以根据需要在任何时间（编译时或运行时）修正类的行为，它会有什么优点，有什么缺点，它的真正意义在哪？

（我想理解模式是一回事，要正确地描述模式又是另外一回事了）hegong121cOj33FuMcb.gif

动态接口可以这样实现：
class book {
HashMap interfaces；
addinterface（String ifname，String impClassname）
removeInterface（。。。）
object getInterface（String ifname）
}

use:
bookImp.addinterface("digest","mydigestimp");

digest dig=(digest)bookImp.getInterface("digest")
dig......
具体实现getinterface（）时，采用reflect机制

我想动态接口再加上人工智能方面的东西，感觉就可以开发出一个具有高度智能，自我进化的软件（有生命的软件！）