近來因為臨近畢業，而且論文已經寫得差不多了，故想借點書看以免虛度過多。初翻《深入淺入面向物件分析與設計（中文版）》這本書時，雖然有500多頁，但看裡面插圖不少，於是決定看。前幾章介紹的內容感覺有點“吹”，什麼偉大的軟體由此開始……云云。當然，儘管介紹的知識比較簡單，但還是一些原則值得記錄的，儘管這些原則原本就在不同的地方接觸到過：

       1.軟體開發過程：需求->用例->UML表示的類圖->實現。分析與設計主要難點在把用例等對映到類圖部分，而從類圖到實現，只是簡單的填空工作，可不需要討論。有了類圖，就可以寫單元測試用例了，以單元測試用例此作為驗收標準。軟體是經常變化的，但變化應該從需求文件開始修改，重複整個過程，而不要期望軟體修改只在程式上修改，這是比較規範的開發方式。

       2.軟體編碼設計時，多考慮將變化和不變的部分分開，即使它們是屬於同一個物件，也可以考慮試著把經常變化的屬性和不變的屬性分開。在一個類中，若有某個方法可能因其它類的改變而面臨著改變時，把變化部分提出來，寫成函式物件比較好！

       3.UML中的關聯（單向"->"箭頭）與聚合（單向"◇"箭頭）。共同點是二者都需要在類1中持有類2的引用，但區別是：關聯是兩個相互獨立的類，並具有相互之間的組成與包含關係，更多用來表現業務關係（比如在系統中，聲音識別器持有一個門的引用，用來控制門的開關，這二者沒有組成關係，只有業務關係），而聚合更多表現的是實體之間的關係，是部分組成整體的意思，其中實心的聚合表示該部分不可或缺（比如Person類有Name類的引用，二者是不可或缺的聚合關係）。（看來我以前寫過很少錯誤的UML類圖）

       4.OO原則：

• 將變化之物封裝起來
• 對介面編碼
• 應用程式中的每一個類只有一個改變的理由。

       不過看了幾章過後，慢慢就進入狀態了，特別是本文中通過一個例子，不斷地完善，不斷地變化需求要求完善……。此時會發現之前那些可以簡單想到的程式設計方式，已經不能滿足軟體的需求了，而且軟體漸漸變得越來越複雜。直至遇到一個我之前也常常困惑的問題：

在一大批子類中有兩個子類有些相似，甚至此種情況還在很大其它的子類中出現，如果每個類都確實寫一個類，則有很多重複程式碼，若抽象出這兩個類的共同父類則有點不倫不類，但其相似性又不足以抽象成整體各個子類的父類！怎麼辦？書已經進展到234頁了，讓我明天再去尋找答案吧。今天先休息了，哈哈。