物件導向分析與設計 ch5~8

1. 物件導向
分析與設計
Brett D.McLaughlin, Gary Pllice & David West
You-Hsuan Yu
2018/4/23
Ch 5 ~ Ch 8

2. • 容易易變更更的類別不⼀一定就是⾼高內聚⼒力力; 若若是⼀一個類別裡的很多功能是很不相關的，雖然
容易易變更更但是就不是⾼高內聚⼒力力，因為內聚⼒力力代表的是類別裡聚焦的功能都是同⼀一個⽅方
向 (不能很發散)
• (解釋圖: 類別裡就只有吉他，就是屬於⾼高內聚⼒力力，但若若是多了了很多其他的東⻄西例例如曼陀
鈴等，就越來來越發散，變成內聚⼒力力低;
• 最後改進成搜尋樂器，樂器是實體，不是抽象的，規格也是實體不是抽象，表⽰示這指
的是唯⼀一的“樂器”跟“規格”，⽽而吉他和曼陀林林等樂器就放在規格裡的property，優點
就是倉庫裡的樂器跟規格都很單純⼀一樣，不會很發散，為⾼高內聚⼒力力
內聚⼒力力

3. • 將問題依照功能分成很多⼩小問題，很多⼩小問題組成⼀一個完整的⼤大問題
• 步驟：
• 1.功能清單 - 與客⼾戶討論 (從中聽出共通性(相似)，變化性(不相似))
• 2. 使⽤用案例例圖 -需求和功能差別不⼤大，不需要糾結
-系統整體輪輪廓( v.s. “使⽤用案例例” - 系統細節)
-每個橢圓代表⼤大⽅方向的每⼀一個需求/功能，系統要做的事
這就是”領域分析” (客⼾戶的語⾔言)
3. 將系統分解成模組
4. 設計模式：ex: MVC
如何解決⼤大的專案

4. • 找出功能(feature)清單裡“最重要”功能，從那裡開始著⼿手
• 架構三問
(Q2-會有額外需求，這階段要弄弄清楚)
• 減少風險
• 使⽤用情節(senario) 有助於減少風險 - 像是為要著⼿手的重要功能舉幾個實際的例例⼦子去跑
-沒那麼細節版的使⽤用案例例
-專案初期時使⽤用 (但是若若真實情況有很多替代路路徑，就有可能錯過⼀一些重要需求)
-當沒有完整需求清單、⼀一群使⽤用案例例時，⽤用來來確定模組的基礎
在這階段處理理細節不是重點，並且依照開出來來的需求去實作，不追求最⼤大彈性(因為
要減少風險，不要太複雜)
架構(Design Structure)-模組之間的聯聯繫

5. p.350 為什什麼 Board 要有 Unit的實例例 ? 都可但優點？
當不確定某項功能的意義為何時
1. 詢問客⼾戶
｜ 該功能的意義為何？
2. 共通性分析
｜ 如何在我的系統裡實現該功能？
3. 實作計畫

6. • 下⼀一個關鍵功能選跟已經建立好物件有關⻄西的，是最容易易/好的
• 關鍵功能：靜態物件 v.s. 動作
• 當不同事比相同事還多時，可能就沒有⼀一個良好、通⽤用的解法
共通性分析

7. 設計原則 #1 - Open-Close Principle (OCP)
• closed for modification, open for extension
• 關乎彈性
• 封裝與抽象化的結合
• 舉例例1：繼承 (close) 然後 override (open)
• 舉例例2 : 類別裡 fileprivate 、 public

8. 設計原則 #2 - Don’t Repeat Yourself Principle (DRY)
• 避免重複的程式碼，減少後續問題
• 關乎⼀一個地⽅方⼀一個需求
• 讓系統裡每⼀一個資訊與⾏行行為的片段，都存在於單⼀一、合理理的地⽅方
(需求與功能清單裡的片段功能不應該重複)
-> 也就是說，特定片段的資訊與⾏行行為具有單⼀一來來源 (single source)

9. 設計原則 #3 - Single Responsibility Principle (SRP)
• 關乎責任
• 與 DRY 相關 - DRY 把⼀一個功能性片段放在單⼀一地⽅方 (類別)，SRP 確認⼀一個類別只
做⼀一件事，沒有其他類別共同分擔該⾏行行為
• 這⼀一件事可以是很⼤大的⽅方向
• 導致通常使⽤用 SRP 的類別會更更⼤大(?) - 因為相同⽬目標的功能會放在同⼀一類別，但是
整體有較少類別
• SRP 就是內聚⼒力力 (⾼高度內聚⼒力力的軟體，越正確運⽤用 SRP)
• 檢查⽅方法：The (類別) (⽅方法) itself.
• ex: The automobile starts itself. (O)
• The automobile drives itself. (X -driver)

10. 設計原則 #4 - Liskov Substitution Principle (LSP)
• 關乎設計良好的繼承
• ⼦子類別要可以完全取代⺟母類別
• 繼承
• 委派
• 合成
• 聚合