一.行為等價性
根據規約判斷是否行為等價
單純的看實現**，並不足以判定不同的implmentation是否是「行為等價的」
需要根據**的spec（開發者與client之間形成的contract）判定行為等價性
在編寫**之前，需要弄清楚spec如何協商形成、如何撰寫
二.前置與後置條件
前置條件：對客戶端的約束，在使用方法時必須滿足的條件
後置條件：對開發者的約束，方法結束時必須滿足的條件
除非在後置條件裡宣告過，否則方法內部不應該改變輸入引數
避免使用可變的全域性變數！可變資料型別導致程式修改變得異常困難
三.設計規約
規約s2替代s1的條件：規約的強度s2>=s1
前置條件更弱 後置條件更強 就可以用s2替代s1
spec變強：更放鬆的前置條件+更嚴格的後置條件
強弱的比較：
越強的規約，意味著implementor的自由度和責任越重，而client的責任越輕。
更弱的前置條件意味著實現時要處理更多的可能輸入，實現的自由度低了-》面積更小
是否使用前置條件取決於(1) check的代價；(2) 方法的使用範圍
如果只在類的內部使用該方法(private)，那麼可以不使用前置條件，在使用該方法的各個位置進行check——責任交給內部client；
如果在其他地方使用該方法(public)，那麼必須要使用前置條件，若client端不滿足則方法丟擲異常。
規約先行 （二十一）設計規約
強制 儲存方案和底層資料結構的設計獲得評審一致通過，並沉澱成為文件。說明 有缺陷的底層資料結構容易導致系統風險上公升，可擴充套件性下降，重構成本也會因歷史資料遷移和系統平滑過渡而陡然增加，所以，儲存方案和資料結構需要認真地進行設計和評審，生產環境提交執行後，需要進行 double check。正例 ...
軟體構造 課程提綱4
第六章 可維護性的常見度量指標 圈複雜度 行數 運算子 運算元的數目 可維護性指數 mi 繼承深度 類耦合 單元測試覆蓋度 聚合度與耦合度 1 耦合度 多個模組間的相互聯絡 2 聚合度 模組內部語句或語句段之間的聯絡 solid 1 s 單一責任原則，即引起類變化的原因只有乙個 2 o 開放封閉原則...
軟體構造設計模式（上）
visitor訪問者模式 observer觀察者模式 template模版模式 decorator裝飾器模式 adapter介面卡模式 指物件有某個行為，但在不同的場景中，該行為有不同的實現演算法。定義一系列演算法類，將每乙個演算法封裝起來，並讓它們可以相互替換。主要目的是將演算法的定義和使用分開，...