最近逐渐形成的一些设计体会是，如果几个对象之间要通过一定数量的接口调用来协同实现一个use case的话，那么，无论让哪个对象启动这种调用都会让人不爽，一方面会在选择对象A还是对象B作为启动对象而犹豫不决，另一方面，又使得对象之间彼此暴露了接口。
我的一个概念是，不同的逻辑对象之间，是孤立而无联系的。这是一个逻辑概念，于语言机制带来的概念不同，语言所提倡的是暴露接口，隐藏实现细节。而我所期待的是，隐藏接口，不同的逻辑对象之间，根本就不需要知道对方的接口，也无需关心如何同其他对象交互，它们，是孤立的。
那么如何实现use case呢？如何完成对象交互呢？很简单，既然逻辑对象不适合做这件事情，那么就让驱动对象来实现就好了。结果是，逻辑对象本身提供只操作自身的接口（不再驱动别的对象了），而驱动对象则调用这些逻辑对象的接口来实现use case，实现某种交互。

一个问题解决，另一个问题诞生。驱动对象实现某use case的接口由谁调用？何时被调用？通常是由上一级的家伙调用，大不了就是到了main函数那罢了。但是何时被调用呢？
驱动对象能驱动的use case通常分为两类，一类是需要在程序的每个循环内都必须调用的，另一类是在特有条件出现后才能调用的。
那么，后一类何时调用呢？一个方案是，在程序的每个循环内轮询是否出现了特有条件，如果出现就调用驱动对象的相应接口。这显然不是一个好提议。而另一个方案，就是消息队列了。特定条件，通常都是某个对象产生的某种状况，并且产生时机不定，因此当特定条件产生后，将该条件抽象为一条消息，加入到消息队列中，是最好不过的了。然后在程序的每个循环中，轮询消息队列是否有消息，有消息则处理之（驱动对象的某接口调用）。连轮询都不想的话，利用windows消息队列也可以，可以得到操作系统级的支持，不过移植之类的也相应困难呢。

要运用消息队列，必须提供一个全局的消息队列对象/接口，以便任何对象都能向队列添加消息。也就是说，必须破坏局部性建议，每个对象都可能在某个时候随意的使用该对象/接口，但这并不会像书上说的会容易出错，而是多线程烦恼，还有重用烦恼，因为一旦你要重用这其中的东西，就表示你必须附带遵循同样的消息队列模式。
消息队列的一个问题是，滞后性。windows消息队列也许没有问题，但是消息队列对象却有，因为消息的处理将会留到消息队列被询问的时候，当然，极度期望条件一产生，相应use case就要被调用的事情还是极少的吧，至少我还没有碰到过。