開拓視野

Ted

傳統

• 將物件視為資料和方法的簡單集合

• 封裝視為資料隱藏

• 繼承 = 特殊化再利用

新• 將物件視為具有責任的東西

• 封裝視為隱藏一切的一種能力

• 繼承 = 物件分類的一種方法

其他還有

• 共通性與可變性分析

• 概念視角，規約視角，實作視角抽象類別與衍生類別的關係

• 設計模式與敏捷程式設計方法的差別(冗餘性，可讀性，測試性)

具有責任

• 傳統的看法 –物件只是一種資料處理的方法

• 新的看法-物件具有一個責任的實體

– 1.初步設計(不在乎細節)

– 2.實作該設計

• 只關注介面

• Shape物件的責任

– 知道自己的位置

– 能在螢幕上描繪自己

– 能從螢幕上移除自己

封裝

• 傳統 –資料隱藏

• 新的看法-任何形式的隱藏

– 實作細節

– 衍生類別

– 設計細節

– 實體化規則

• 傘的故事-

• Shape shape = new Rectangle()– 類別的封裝

• Shape.Display() – 實作細節的封裝

• 使用adapter模式將Third-Party Circle 封裝進Circle– 其他物件的封裝

• Rectangle / Triangle/Circle的資料只存在自己的class 內部– 資料的封裝

• 弱內聚: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 class

敏捷開發與設計模式

• 設計模式:需要預先設計的概念

• 敏捷開發:不預先設想

• 衝突?!

• 重點在於皆要求程式碼具備一定的品質• 無冗餘，可讀，可測試• Once and only Once Rule

– 程式碼和測試必須能夠表達一切(可讀)– 不包含重覆程式碼

• 依介面設計，找到變化之處使程式碼高度內聚，消除冗餘

• 為避免耦合，程式碼必須封裝在定義明確的介面之後

• 反應意圖

• 可測試性是敏捷開發的核心

• 先寫測試

– 必能得到至少一組測試

– 可測試得程式必定鬆耦合，且良好封裝

– 關注測試會使概念分成多個可測試部分，進而造成強內聚，鬆耦合

• 可測試性

• 內聚:容易測試因為程式碼只負責一項責任

• 鬆耦合:因為需操心的資料較少

• 冗餘程式碼:太多會造成測試涵蓋率下降

• 可讀性好:容易瞭解程式意圖

• 封裝性好:鬆耦合

最後

• 封裝可用來建立物件之間的layers (介面?!)

– 如此可以在layer的一側改東西而不影響另一側