開拓視野
Ted
傳統
• 將物件視為資料和方法的簡單集合
• 封裝視為資料隱藏
• 繼承 = 特殊化再利用
新
• 將物件視為具有責任的東西
• 封裝視為隱藏一切的一種能力
• 繼承 = 物件分類的一種方法
其他還有
• 共通性與可變性分析
• 概念視角,規約視角,實作視角抽象類別
與衍生類別的關係
• 設計模式與敏捷程式設計方法的差別(冗餘
性,可讀性,測試性)
具有責任
• 傳統的看法 –物件只是一種資料處理的方法
• 新的看法-物件具有一個責任的實體
– 1.初步設計(不在乎細節)
– 2.實作該設計
• 只關注介面
• Shape物件的責任
– 知道自己的位置
– 能在螢幕上描繪自己
– 能從螢幕上移除自己
封裝
• 傳統 –資料隱藏
• 新的看法-任何形式的隱藏
– 實作細節
– 衍生類別
– 設計細節
– 實體化規則
• 傘的故事-
• Shape shape = new Rectangle()
– 類別的封裝
• Shape.Display()
– 實作細節的封裝
• 使用adapter模式將Third-Party Circle 封裝進
Circle
– 其他物件的封裝
...
• 弱內聚:Circle還必須關注SpecialCircle
• 減少再利用的可能性:假設今天要畫三角型
是否就必須重寫一次繪製虛線的method
• 無法根據變化良好伸縮:假設有多種不同線
條的原型需要繪製,程式是否因此而重複
發現變化並封裝
• 傳統:發現變化並資料隱藏?!
• 新的看法:發現變化並類型封裝
– Shape shape = new Rectangle();
舉例
• 每種動物都有數量不同的腿
• 動物物件必須能夠記住並獲取這一資訊
• 每種動物的移動方式都不同
• 對於指定的地形類型,動物物件必須能夠
計算出往返的時間
變化
• 腿數的變化
• 移動方式的變化:走,飛,游
• 用一個資料成員說明我的物件永有哪種移
動方式
• 大量重複的程式碼
• 用兩種類型的animal類別
• 看似可行 but……
• 當變化變多時…. 物件爆炸!!
• 或者使用switch來分別肉食或草食動物
• 當一個class處理越多事情,內聚性就會變差
• 處理越多特殊情況理解性越差
A better way
共通性和可變性分析與抽象類別
• 鋼筆,鉛筆,毛筆
– 都是書寫工具 (共通性)
– 製作的材質(變性)
• 共通性分析為架構提供長效的要素
• 可變性促進實際使用所需
• 共通性:定義了關聯,概念,抽象類別
• 可變性:具體類別
概念
軟體要負責甚麼(abstract)
規約
怎麼使用軟體(interface)
實作
軟體怎麼履行責任
(implementation)
• 抽象類別(共通性):需要用甚麼介面來處理這
個類別的所有責任
• 衍生類別(可變性):對於這個指定的實作(這
個變化),應該怎樣根據指定的規約來實作
他
• 概念視角Behavior class要負責甚麼: 移動的
行為
• 怎麼使用Behavior class : behavior.move()
– Method訂定
• Behavior class如何移動: Fly class & walk...
敏捷開發與設計模式
• 設計模式:需要預先設計的概念
• 敏捷開發:不預先設想
• 衝突?!
• 重點在於皆要求程式碼具備一定的品質
• 無冗餘,可讀,可測試
• Once and only Once Rule
– 程式碼和測試必須能夠表達一切(可讀)
– 不包含重覆程式碼
• 依介面設計,找到變化之處使程式碼高度內聚,
消除冗餘
• ...
• 可測試性是敏捷開發的核心
• 先寫測試
– 必能得到至少一組測試
– 可測試得程式必定鬆耦合,且良好封裝
– 關注測試會使概念分成多個可測試部分,進而
造成強內聚,鬆耦合
• 可測試性
• 內聚:容易測試因為程式碼只負責一項責任
• 鬆耦合:因為需操心的資料較少
• 冗餘程式碼:太多會造成測試涵蓋率下降
• 可讀性好:容易瞭解程式意圖
• 封裝性好:鬆耦合
最後
• 封裝可用來建立物件之間的layers (介面?!)
– 如此可以在layer的一側改東西而不影響另一側
設計模式的解析與活用 -開拓視野
Upcoming SlideShare
Loading in …5
×

設計模式的解析與活用 -開拓視野

498 views

Published on

設計模式的解析與活用 -開拓視野

Published in: Software
  • Be the first to comment

設計模式的解析與活用 -開拓視野

  1. 1. 開拓視野 Ted
  2. 2. 傳統 • 將物件視為資料和方法的簡單集合 • 封裝視為資料隱藏 • 繼承 = 特殊化再利用 新 • 將物件視為具有責任的東西 • 封裝視為隱藏一切的一種能力 • 繼承 = 物件分類的一種方法
  3. 3. 其他還有 • 共通性與可變性分析 • 概念視角,規約視角,實作視角抽象類別 與衍生類別的關係 • 設計模式與敏捷程式設計方法的差別(冗餘 性,可讀性,測試性)
  4. 4. 具有責任 • 傳統的看法 –物件只是一種資料處理的方法 • 新的看法-物件具有一個責任的實體 – 1.初步設計(不在乎細節) – 2.實作該設計 • 只關注介面
  5. 5. • Shape物件的責任 – 知道自己的位置 – 能在螢幕上描繪自己 – 能從螢幕上移除自己
  6. 6. 封裝 • 傳統 –資料隱藏 • 新的看法-任何形式的隱藏 – 實作細節 – 衍生類別 – 設計細節 – 實體化規則 • 傘的故事-
  7. 7. • Shape shape = new Rectangle() – 類別的封裝 • Shape.Display() – 實作細節的封裝 • 使用adapter模式將Third-Party Circle 封裝進 Circle – 其他物件的封裝 • Rectangle / Triangle/Circle的資料只存在自己的 class 內部 – 資料的封裝
  8. 8. • 弱內聚:Circle還必須關注SpecialCircle • 減少再利用的可能性:假設今天要畫三角型 是否就必須重寫一次繪製虛線的method • 無法根據變化良好伸縮:假設有多種不同線 條的原型需要繪製,程式是否因此而重複
  9. 9. 發現變化並封裝 • 傳統:發現變化並資料隱藏?! • 新的看法:發現變化並類型封裝 – Shape shape = new Rectangle();
  10. 10. 舉例 • 每種動物都有數量不同的腿 • 動物物件必須能夠記住並獲取這一資訊 • 每種動物的移動方式都不同 • 對於指定的地形類型,動物物件必須能夠 計算出往返的時間
  11. 11. 變化 • 腿數的變化 • 移動方式的變化:走,飛,游
  12. 12. • 用一個資料成員說明我的物件永有哪種移 動方式 • 大量重複的程式碼
  13. 13. • 用兩種類型的animal類別 • 看似可行 but……
  14. 14. • 當變化變多時…. 物件爆炸!!
  15. 15. • 或者使用switch來分別肉食或草食動物 • 當一個class處理越多事情,內聚性就會變差 • 處理越多特殊情況理解性越差
  16. 16. A better way
  17. 17. 共通性和可變性分析與抽象類別 • 鋼筆,鉛筆,毛筆 – 都是書寫工具 (共通性) – 製作的材質(變性) • 共通性分析為架構提供長效的要素 • 可變性促進實際使用所需 • 共通性:定義了關聯,概念,抽象類別 • 可變性:具體類別
  18. 18. 概念 軟體要負責甚麼(abstract) 規約 怎麼使用軟體(interface) 實作 軟體怎麼履行責任 (implementation)
  19. 19. • 抽象類別(共通性):需要用甚麼介面來處理這 個類別的所有責任 • 衍生類別(可變性):對於這個指定的實作(這 個變化),應該怎樣根據指定的規約來實作 他
  20. 20. • 概念視角Behavior class要負責甚麼: 移動的 行為 • 怎麼使用Behavior class : behavior.move() – Method訂定 • Behavior class如何移動: Fly class & walk class
  21. 21. 敏捷開發與設計模式 • 設計模式:需要預先設計的概念 • 敏捷開發:不預先設想 • 衝突?!
  22. 22. • 重點在於皆要求程式碼具備一定的品質 • 無冗餘,可讀,可測試 • Once and only Once Rule – 程式碼和測試必須能夠表達一切(可讀) – 不包含重覆程式碼 • 依介面設計,找到變化之處使程式碼高度內聚, 消除冗餘 • 為避免耦合,程式碼必須封裝在定義明確的介 面之後 • 反應意圖
  23. 23. • 可測試性是敏捷開發的核心 • 先寫測試 – 必能得到至少一組測試 – 可測試得程式必定鬆耦合,且良好封裝 – 關注測試會使概念分成多個可測試部分,進而 造成強內聚,鬆耦合
  24. 24. • 可測試性 • 內聚:容易測試因為程式碼只負責一項責任 • 鬆耦合:因為需操心的資料較少 • 冗餘程式碼:太多會造成測試涵蓋率下降 • 可讀性好:容易瞭解程式意圖 • 封裝性好:鬆耦合
  25. 25. 最後 • 封裝可用來建立物件之間的layers (介面?!) – 如此可以在layer的一側改東西而不影響另一側

×