《道法自然》第六章讀後感

第六章 架構分析：功能分解vs對象分析

    兩個收穫：

    1、功能分解是一種縱向分層，對象分析則完全可以通過合理的組合形成橫向分層。縱向分層中，每一層均是一杆子從上直到下，從介面直到資料庫，顯然給軟體的分析、維護帶來了極大的困難，更不利於軟體的功能擴充。而橫向分層，層間耦合完全可以通過適當的組合達到最少，並且通過限制層間關係，使單個層的實現簡單化、易替換，便於團隊協作開發大型軟體。

    2、層、子系統和包的概念，以前一直非常糊塗。現在總算弄清了：一般來說，層>子系統>包。這三個概念無非是對象封裝概念的外延。

    包不過是各個功能相似的類的彙總；

    子系統與類的主要區別：只能被動接受訊息，不能主動發送訊息，即子系統是一個完全封閉的系統。兩點注意：1）注意與面向過程分析所劃分的子系統是完全不同的；2）子系統設計本質上是OO設計的範圍，而不是OO分析的範圍。

    層與類的主要區別：層只能按約定，向相鄰層發送或接收訊息。

    從上述理解來看：除最底層可以單獨作為一個子系統外，其餘層均無法單獨作為子系統，而只能包含子系統。

    兩點疑惑：

    1）子系統必須實現一個介面，這個觀點很好，但如何?介面呢？又如何來調用這個介面呢？是不是必須顯式地定義介面？有的子系統包括幾個類或包，幾個類或包如何?一個介面？

    2）MVC架構在概念上是理解了，但尤其VC的實現，存在諸多耦合，比如說單擊一個按鈕後，可能不僅要執行一個操作，而且要改變某個視窗顏色。當然可以將視圖層的單擊事件分解為兩個事件：調用視圖層的改變顏色方法，調用模型層的邏輯處理。但有好多操作都不過簡單到了一句話，這樣太羅嗦了。是不是應該這樣：形成M--V--VC架構，V主要實現核心邏輯功能（不論採用哪種介面一定會有的功能，如計算總值）；而VC中實現次要的、不穩定的邏輯功能？