分析模式（可複用的對象模型）- 讀書筆記

 

讀後感：

Martin Fowler 20年前的書，OO和領域的思想對於今天的咱們來講很基礎，但在那時應該算是萌芽。Smalltalk語言簡單，語法中省略空格可能由於那時的硬件設備昂貴，而不得不作出的選擇，可是可讀性真的不好，而書中基本是用Smalltalk進行示例。翻開這本書是爲了查找財務模型，它沒有讓我失望，特別是第6章「庫存與財務」給了我思惟建模的概念。這本書和UML、GOF的「設計模式」差很少是在同一時間段出現，因此書的內容看上去有點古董的感受。不過，大師的思路有時候都是接近的。這本書還讓我聯想到，其實軟件開發領域這幾十年並無改變多少，對比更新迭代很快的手機來講，咱們算是很幸運的了。

 

讀書筆記：

第1章 緒論

建模原則：概念模型是與接口（類型）而不是與實現（類）相關聯的。

建模原則：模式是起點，而不是終點。

建模原則：模型無好壞對錯之分，只有有用仍是無用之分。

做者的電子郵件（郵件地址是100031.3311@compuserve.com）

 

第3章 觀察和測量模式

關鍵概念：數量、單位、測量、觀察、觀察概念、現象類型、關聯函數、被否決的觀察、假設

建模原則：當多個屬性與可能會在幾個類型中使用的行爲相關時，就把這些屬性組合成新的基礎類型。

建模原則：操做級中的對象會常常發生變化。它們的配置由不多發生變化的知識級來約束。

建模原則：若是某個類型擁有多種類似的關聯，能夠爲這些關聯對象定義一個新的類型，並創建一個知識級類型來區分它們。

 

第4章 針對公司財務的觀察模式

關鍵概念：企業片段、維度、測量方案、狀態類型

 

第6章 庫存與財務

關鍵概念：帳目、事務、條目、記入規則

建模原則：要記錄一個值的變動歷史，能夠爲這個值設立一個帳目。

事務明確地把取款條目和存款條目聯繫起來。雙條目法反映一個基本的帳務原理。

建模原則：在使用帳目時要遵照守恆原理：須要清算的物品不能憑空生成和消失，它僅僅是從一個地方轉移到另外一個地方。這使得發現和防止不守恆變得容易。

可逆性：記入規則的一個重要屬性就是它們一定是可逆的。一般咱們不能刪除一個錯誤的條目，由於它要麼是支付的一部分，要麼出如今帳目清單上。咱們清除它的做用的唯一方法就是輸入一個一樣的可是相反的條目。

建模原則：爲了確認計算是如何進行的，把計算的結果表示成對象，由它來記住是由哪一個計算產生的結果以及計算所使用的輸入值是什麼。

 圖釋：若是使用多重彙總帳目，有可能會定義一個具備重疊細目帳目的彙總帳目。集合元素不容許重複。

 

若是以爲真的是個問題，咱們就要在組合關係上加以限制，這個限制不容許咱們選擇帶有重複的子帳目。 

伊利諾伊大學厄巴納-尚佩恩分校的研究人員已經在開發帳務框架方面作了大量工做。

 

第12章 信息系統的分層構架

咱們看到會存在這樣的狀況：GUI開發者理解用戶界面環境可是根本不須要了解領域模型，而外觀開發者理解領域模型可是不須要知道GUI開發。表示層/應用邏輯層的分離把須要的不一樣技術分割開來，從而使開發者爲了作出貢獻只須要學習較少的東 咱們看到會存在這樣的狀況：GUI開發者理解用戶界面環境可是根本不須要了解領域模型，而外觀開發者理解領域模型可是不須要知道GUI開發。表示層/應用邏輯層的分離把須要的不一樣技術分割開來，從而使開發者爲了作出貢獻只須要學習較少的東西。

 

這個分離容許從一個單獨的外觀開發出多種表示。

 

外觀爲測試提供一個很好的平臺。當外觀和表示層被合併時，基礎的計算只可以經過GUI進行測試，這須要手工測試（或者針對迴歸測試的GUI測試軟件）。當這些被分隔開時，就可以爲外觀的接口編寫一個測試程序。這樣一來，只有表示層代碼須要使用比較笨拙的工具來測試。

 

這個過程會發生一個例外，就是應用須要一個特殊的數據配置發生做用，而且在開始時只用一個步驟就可以從數據庫中得到該數據，以便改善性能。在這種狀況下，一個有用的作法是領域層提供針對具體應用的裝載請求，這種請求給應用一個機會讓領域層知道它想要請求什麼。在某種程度上，這損害了領域層不該當知道什麼應用使用它的原則，可是在一些環境中性能的改善是強制的。

 

一個解決方法是增長另外一個層次——數據庫接口層，它負責從數據庫中爲領域層裝載數據和當領域改變時更新數據庫。這個層也負責處理輸入以及其它遺留交互。