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