但是，隨后的幾個程序也是如此，不盡人意。其間我也是一直在讀關于Command模式和一些程序的代碼，但是就是沒有能夠領悟到應該怎樣完成我的程序才算是個較優的選擇。
其間問了一些朋友，但是他們給的答復都是，要多寫代碼才能理解，有時頓悟是很重要的。
實際上，這一切都源自于我對MVC那淺薄的認知。當然，現在也是很淺薄的。我錯誤的將邏輯控制與界面控制都非常單純的交給了Control這個部分，從而讓本來屬于業務和界面控制的代碼在M-C處被混合后又不自然的割裂開來。
為什么會做這個失誤的判斷，我想了很久。
從現在來看，我覺得是因為自己過于重視“耦合”而輕視了內聚。盡管在分成兩層以后，邏輯和界面之間的耦合度降低了，但是程序邏輯自身和界面邏輯都不同程度的引入了黏合部位的內容而影響程序的結構。
在總結了以往的經驗和教訓以后，我現在開始在新的程序里面嘗試將程序分成三層。界面一層，界面控制一層，這一層基本上是純粹的窗口設計代碼，以及一些必要的提交到下一層的通知；邏輯-界面的通訊與界面控制一層，這層的職責是加工界面獲取的信息，在界面控件間協調控制，并處理消息通知邏輯層，可以視作是視圖的“文檔”；最后一層是邏輯層。
當然，目前僅僅在幾個小程序中采用了這樣的設計，也不太清楚副作用究竟怎么樣，所以只是說給大家提供一個借鑒而已。至于最重要的經驗，那就是，有時候，不能太看重“耦合”了，還是應該關注一下，對象本身的內聚性如何。