1.4 迭代模型
ood啟思錄
軟體開發的迭代模型看上去和瀑布模型差不多，區別只在於迭代模型允許開發者沿專案流程往返（見圖1.2）。如果我們在為系統的某個部分編寫**時發現了乙個設計缺陷，我們可以回到設計階段來分析並改正它。或者，如果我們在測試系統的一部分時發現了新的系統需求，我們可以回到分析階段來修正這個問題。在面向動作范型中，迭代模型會帶來很多問題。面向動作的軟體常常會有很多位於資料和行為之間的隱含依賴關係。再同集中控制機制一結合，你就會發現自己處於這樣乙個境地：如果觸動了已經存在的應用程式的部分，整個系統就會轟然倒塌。如果已經為應用程式編寫了90%的**，那麼增加需求或者改變設計是無法接受的。物件導向范型改正了這一問題，它向開發者提供分布式的流程控制，並使他們具備防止資料、行為間隱含依賴性的能力。於是，對物件導向開發者來說，軟體開發的迭代模型就成了理所當然的選擇。1
但是，迭代模型也不是一點問題都沒有。雖然我相信，這個模型準確地反映了從系統構架師角度上看到的開發過程，但是對專案經理來說，它卻帶來了很大的問題。簡而言之，這個模型目前缺乏一系列精確定義的開發里程碑。這並不意味著在整個軟體系統構築完畢移交客戶的那一天之前，專案經理無法獲得任何反饋；而是表明我們需要新的迭代式的里程碑來在應用系統成型之前就提供必要的反饋。
一種這樣的工件（deliverable）是軟體原型（software prototype）。原型領域源自這樣的認知：現實世界中的複雜實體是逐漸生長而成的（grown），而不是建立而得的（built）。很多開發者都把原型看作是控制當今軟體根本複雜性的方法。通過建立原型，應用程式可以一次增長一層，每層都經過徹底的測試，然後才開始下一層的增長。通過這種方法，設計缺陷就可以盡早發現，從而改正的代價也相對較低。而工作原型也可以用作生產率的衡量尺度。通過衡量原型中功能點的數目並將其同偽功能點（尚未真正實現其功能）相比較，我們可以跟蹤進度。2
《OOD啟思錄》 第1章1 6節 軟體復用性
1.6 軟體復用性 ood啟思錄 控制根本複雜性的另一種方法是乾脆避免開發軟體。如果能買到軟體，何必要建立它呢？我們的mis開發者並不建立他們的關聯式資料庫，而是購買現成的產品。如果你需要電子資料 你也不會自己建立乙個，你會從lotus microsoft borland或者其他的 商購買。購買軟體...
《OOD啟思錄》 書摘精要
p7 本身沒什麼意義，從 提煉出來的無形的設計才是真正有價值的 的尺寸 或者說粒度 和它的靈活性成反比 p13 經驗原則 2.1 所有資料都應該隱藏在它所在的類內部 p15 經驗原則 2.2 類的使用者必須依賴類的公有介面，但類不能依賴它的使用者 p16 經驗原則 2.3 儘量減少類的協議中的訊息 ...
OOD啟思錄 讀書筆記
object oriented design heuristics arthur j.riel ood啟思錄 美 里爾 riel,a.j.著，鮑志雲譯 北京 人民郵電出版社，2004.7 第二章 類和物件 物件導向范型的建材 經驗原則 2.1所有資料都應當隱藏在它所在的類內部。經驗原則 2.2類的使...