構件級設計
理解構件設計
體系設計——建築平面圖、結構、房間和外部環境之間的連接機制
構件級設計——每個房間的內部細節設計
什麼是構件？
構件是計算機軟件中的一個模塊化的構造塊
系統中模塊化的、可配置的和可替換的部件，該部分封裝了實現並暴露了一組接口。
構件可能包含了一個相互協作的類的集合
OO component
構件設計的四個關鍵問題
- 每個構件應該由哪些類組成
- 類之間的關係是什麼，是否需要優化
- 構建提供的外部接口是什麼
- 每個類具體應該由哪些屬性和成員方法
Component Design
目的
使系統發生變更時更靈活適並且減少副作用的傳播
設計原則
開閉原則（OCP）
對擴展開放，對修改關閉原則。
思想：
需求變化時，不是通過修改類本身來完成，而是通過定義抽象類的新實現完成。
通過抽象類及其接口，定義類的外部行爲特徵，相對穩定，不需要經常修改，因此可以滿足“對修改關閉”。
從抽象類導出的具體類可以改變系統行爲，從而滿足對“擴展開放”。LSP
liskov substitution principle
思想：
在任何父類出現的地方都可以用它的子類來替換，而不影響功能。
能夠保證系統具有良好的拓展性，同時基於類的多態性，能夠減少代碼冗餘，避免運行期的類型判別。
依賴倒置原則
思想：
依賴於抽象。
高層模塊不依賴於底層具體模塊，二者都依賴於抽象。
當兩個模塊之間存在緊密的耦合關係時，最好的方法就是分離接口和實現：在依賴之間定義一個抽象的接口使得高層模塊調用接口，而底層模塊實現接口的定義。
SRP
single responsibility principle
系統中的每一個類都應該只有一個職責（不是一個方法），如果多個職責耦合在一起，會影響複用性。
單一職責原則體現了“高內聚，低耦合”
OO component level Design
步驟1：
標識出所有與問題領域相對應的設計類
設計類不是分析類的簡單映射，一定結構更加優化，且更接近與實現
步驟2：
標識出所有與基礎設施領域相對應的設計類
如界面類、線程調度類，安全控制類，操作系統服務類等。
如定時任務服務，獲取本機用戶名和域服務。
步驟3：
識別每個設計類的屬性
描述類成員方法中的處理邏輯
步驟4：
描述持久的數據類型和管理他的類
步驟5：
詳細描述開發視圖以提供附加的實現細節
Designing Conventional Component
加工邏輯的設計是受算法設計和結構化程序的 管理的
Algorithm Design
the closest design activity to coding
Algorithm Design Model
- 流程圖
- NS圖
- PAD圖
- pseudocode（僞代碼）