但是，随后的几个程序也是如此，不尽人意。其间我也是一直在读关于Command模式和一些程序的代码，但是就是没有能够领悟到应该怎样完成我的程序才算是个较优的选择。
其间问了一些朋友，但是他们给的答复都是，要多写代码才能理解，有时顿悟是很重要的。
实际上，这一切都源自于我对MVC那浅薄的认知。当然，现在也是很浅薄的。我错误的将逻辑控制与界面控制都非常单纯的交给了Control这个部分，从而让本来属于业务和界面控制的代码在M-C处被混合后又不自然的割裂开来。
为什么会做这个失误的判断，我想了很久。
从现在来看，我觉得是因为自己过于重视“耦合”而轻视了内聚。尽管在分成两层以后，逻辑和界面之间的耦合度降低了，但是程序逻辑自身和界面逻辑都不同程度的引入了黏合部位的内容而影响程序的结构。
在总结了以往的经验和教训以后，我现在开始在新的程序里面尝试将程序分成三层。界面一层，界面控制一层，这一层基本上是纯粹的窗口设计代码，以及一些必要的提交到下一层的通知；逻辑-界面的通讯与界面控制一层，这层的职责是加工界面获取的信息，在界面控件间协调控制，并处理消息通知逻辑层，可以视作是视图的“文档”；最后一层是逻辑层。
当然，目前仅仅在几个小程序中采用了这样的设计，也不太清楚副作用究竟怎么样，所以只是说给大家提供一个借鉴而已。至于最重要的经验，那就是，有时候，不能太看重“耦合”了，还是应该关注一下，对象本身的内聚性如何。