最近逐漸形成的一些設計體會是，如果幾個對象之間要通過一定數量的接口調用來協同實現一個use case的話，那么，無論讓哪個對象啟動這種調用都會讓人不爽，一方面會在選擇對象A還是對象B作為啟動對象而猶豫不決，另一方面，又使得對象之間彼此暴露了接口。
我的一個概念是，不同的邏輯對象之間，是孤立而無聯系的。這是一個邏輯概念，于語言機制帶來的概念不同，語言所提倡的是暴露接口，隱藏實現細節。而我所期待的是，隱藏接口，不同的邏輯對象之間，根本就不需要知道對方的接口，也無需關心如何同其他對象交互，它們，是孤立的。
那么如何實現use case呢？如何完成對象交互呢？很簡單，既然邏輯對象不適合做這件事情，那么就讓驅動對象來實現就好了。結果是，邏輯對象本身提供只操作自身的接口（不再驅動別的對象了），而驅動對象則調用這些邏輯對象的接口來實現use case，實現某種交互。

一個問題解決，另一個問題誕生。驅動對象實現某use case的接口由誰調用？何時被調用？通常是由上一級的家伙調用，大不了就是到了main函數那罷了。但是何時被調用呢？
驅動對象能驅動的use case通常分為兩類，一類是需要在程序的每個循環內都必須調用的，另一類是在特有條件出現后才能調用的。
那么，后一類何時調用呢？一個方案是，在程序的每個循環內輪詢是否出現了特有條件，如果出現就調用驅動對象的相應接口。這顯然不是一個好提議。而另一個方案，就是消息隊列了。特定條件，通常都是某個對象產生的某種狀況，并且產生時機不定，因此當特定條件產生后，將該條件抽象為一條消息，加入到消息隊列中，是最好不過的了。然后在程序的每個循環中，輪詢消息隊列是否有消息，有消息則處理之（驅動對象的某接口調用）。連輪詢都不想的話，利用windows消息隊列也可以，可以得到操作系統級的支持，不過移植之類的也相應困難呢。

要運用消息隊列，必須提供一個全局的消息隊列對象/接口，以便任何對象都能向隊列添加消息。也就是說，必須破壞局部性建議，每個對象都可能在某個時候隨意的使用該對象/接口，但這并不會像書上說的會容易出錯，而是多線程煩惱，還有重用煩惱，因為一旦你要重用這其中的東西，就表示你必須附帶遵循同樣的消息隊列模式。
消息隊列的一個問題是，滯后性。windows消息隊列也許沒有問題，但是消息隊列對象卻有，因為消息的處理將會留到消息隊列被詢問的時候，當然，極度期望條件一產生，相應use case就要被調用的事情還是極少的吧，至少我還沒有碰到過。