第2章 類和物件：物件導向范型的建材
ood啟思錄
2.1 類和物件導引
物件導向范型使用類和物件的概念作為基本建築材料。應用程式的分析、設計、實現模型一致地使用這些概念。通過現實世界中的例子來解釋這些概念是最佳方案。如果有一屋子的人，你問：「給你們所需的全部零件，誰能裝配出乙隻鬧鐘」？最多有一兩個人會舉手。但如果你問他們「這個房間裡誰能夠把鬧鈴設到早上9點」，那麼我可以放心地和你打賭，大多數人都會舉手。大多數人會使用鬧鐘，但不會裝配鬧鐘，這難道不荒謬嗎？對這個問題，你最直接的反應當然是「當然不荒謬，你的問題才荒謬呢」！
在現實世界中，有很多東西是我們會使用但不會製造的，比如冰箱、汽車、影印機、計算機等等。這只是列舉了一小部分。為什麼我們可以不知道它們的實現卻能輕鬆使用它們？因為它們被設計為通過乙個精確定義的公有介面[1]來使用。這個公有介面極大地依賴於內部的實現，但又向使用者隱藏了內部實現。這一設計策略還允許鬧鐘製造商把目前鬧鐘用到的60個小零件替換成進口的3個子部件，而鬧鐘的使用者對此不會有意見。
公有介面與實現的另乙個例子可見於汽車行業。很少有駕車者介意機械點火系統（配電盤、電插座、電容器）到電子點火系統的轉變。為什麼？因為公有介面保持了一致，改變的只是實現。但是，請想象一下，如果你去汽車經銷 商處購買新車，經銷商遞給你一把鑰匙，並讓你試車。你坐在駕駛座上，尋找點火裝置的鑰匙孔。你從駕駛杆找到儀表板，再搜尋相鄰區域，卻尋不著鑰匙孔。你問經銷商如何發動汽車。經銷商說，「噢，這個型號是這樣的，你用鑰匙開啟旅行箱，然後你會看到乙個紅色按鈕。按一下那個按鈕汽車就會啟動了。」你會感到不安，因為汽車製造商改變了你熟悉的公有介面。
物件導向范型的乙個基本想法就是這樣。所有構成系統的實現細節都應該隱藏在精確定義並且一致的公有介面後面。使用這些構造的使用者需要知道這個公有介面，但你不讓他們看見實現細節。這樣，如果需要，實現者就可以改變實現細節，只要公有介面保持不變就行。我經常旅行，可以向你保證，不需要知道實現細節就能使用鬧鐘實在很方便。我曾在許多旅館住過，用過很多種鬧鐘，有用電的，有需要上發條的，有依靠電池的，有數字型的，有模擬型的。但是，我坐在飛機上時從未憂慮過不會使用將到達的旅館房間裡的鬧鐘。
我提到「鬧鐘」這個詞後大多數讀者都會知道我指的是什麼，雖然可能你身邊並沒有鬧鐘。為什麼？因為你曾經看見過很多鬧鐘，並且知道，所有的鬧鐘都有一些共同的屬性，比如時間、鬧鈴時間（都按小時和分鐘顯示）以及鬧鈴開關。你還知道，你看到過的所有鬧鐘都允許你設定它們的時間和鬧鈴時間，並且允許你開啟或者關閉鬧鈴。這樣，你就有了一種叫做「鬧鐘」的概念，這一概念用乙個簡潔的組合表示了所有鬧鐘的資料和行為。這種概念稱作類（class）。而你拿在手上的鬧鐘實物叫做鬧鐘類的物件（object）或者例項（instance）。類和物件之間的關係叫做例項化關係（instantiation relationship）。我們說，鬧鐘物件是從鬧鐘類例項化（instantiate）而來，鬧鐘類是你遇到的所有鬧鐘物件的泛化（generalization）[2]（參見圖2.1）。
通過下面的例子，我們可以進一步描述資料隱藏帶來的好處。這是乙個點類，它的實現採用了直角座標系（參見圖2.3）。天真的設計者可能會爭辯說，我們可以把點的x座標和y座標設為公有，因為實現永遠也不會改變。但是，不可避免地，某些新的需求會迫使你改用極座標系，從而會影響使用這個點類的所有使用者。如果我們把資料隱藏起來，那麼只有類的實現者需要改變他們的**。
《OOD啟思錄》 書摘精要
p7 本身沒什麼意義，從 提煉出來的無形的設計才是真正有價值的 的尺寸 或者說粒度 和它的靈活性成反比 p13 經驗原則 2.1 所有資料都應該隱藏在它所在的類內部 p15 經驗原則 2.2 類的使用者必須依賴類的公有介面，但類不能依賴它的使用者 p16 經驗原則 2.3 儘量減少類的協議中的訊息 ...
《OOD啟思錄》 第1章1 4節迭代模型
1.4 迭代模型 ood啟思錄 軟體開發的迭代模型看上去和瀑布模型差不多，區別只在於迭代模型允許開發者沿專案流程往返 見圖1.2 如果我們在為系統的某個部分編寫 時發現了乙個設計缺陷，我們可以回到設計階段來分析並改正它。或者，如果我們在測試系統的一部分時發現了新的系統需求，我們可以回到分析階段來修正...
《OOD啟思錄》 第1章1 6節 軟體復用性
1.6 軟體復用性 ood啟思錄 控制根本複雜性的另一種方法是乾脆避免開發軟體。如果能買到軟體，何必要建立它呢？我們的mis開發者並不建立他們的關聯式資料庫，而是購買現成的產品。如果你需要電子資料 你也不會自己建立乙個，你會從lotus microsoft borland或者其他的 商購買。購買軟體...