設計模式的解析與活用讀後心得

設計模式的解析與
活用讀後心得

在物件導向之前
• 標準結構化程式設計
• 功能分解
• 是不是常常用結構化程式設計及功能分解的方式在寫OO的實作呢？

任務:存取在DB中儲存的形狀描述然後顯示
• 在DB中找到形狀清單
• 打開清單
• 清單依規則排序
• 在顯示器上顯示各種形狀
• 識別形狀TYPE
• 獲取形狀位置
• 以形狀位置作為參數，呼叫顯示形狀的函數

可能的問題在哪？(討論)
• 能者多責，由主程式控制子程式
• 因應變化

該死的需求變化
• 需求總在變化
• 書上列了三個原因(討論)
• 我們永遠無法知道什麼會變化，但我們能夠猜到哪裡可能有變化
• 用函數把變化包起來，透過參數控制
• 用物件導向把變化封裝起來

因應變化：使用功能分解
• 當新增一種形狀時，修改顯示形狀的函數即可(希望如此!)
• 內聚性
• 耦合性
• 修改一個函數甚至是函數的資料都可能對其他函數產生破壞

來個日常生活的例子吧
• 假設你要在一個會議上擔任講師，聽課的人在課後還要去聽別的課程，但是他們不知道下
一堂課的聽課地點，你的責任之一就是確保大家都知道下一堂課去哪上。

功能分解會這麼做
• 獲得聽課的人的名單
• 對於名單上的人
• 找到他或她要聽的下一堂課
• 找到該課的聽課地點
• 找到從這間教室到下一堂課的地點怎麼走
• 告訴這個人怎麼去上下一堂課

日常生活中你會這麼做
• 把下一堂課的地點和其他教室的位置貼在教室後面
• 請大家自己去後面看
• 預期每個人知道自己下一堂要上什麼課

差異是？
• 責任的轉移
• 因應需求的變化
• 需要給研究生特殊指示的時候

軟體開發過程中的視角
• 概念：軟體要負責什麼
• 你要做什麼，而非如何去做
• 規約：怎麼使用軟體
• 實作：軟體如何履行自己的責任

終於可以進入物件導向了
• 何謂物件？
• 帶有方法的資料？
• 具有責任的東西!!
• 自己負責自己且清楚的定義責任
• 視角框架
• 概念：物件是一組責任
• 規約：可被其他物件或自己呼叫
• 實作：物件是程式碼和資料，以及它們之間的計算交流

在教室的例子中
• STUDENT類別
• 程式開始
• 實體化學生的集合
• 告訴此集合，讓學生自己去立法院下堂課的教室
• 集合讓學生去自己下堂課的教室
• 每個學生：
• 找到自己下堂課教室
• 決定怎麼去
• 去那裡

變化來了!
• 大學生、研究生
• 集合要怎麼放兩種不同的類別實體？
• GENERALIZE(一般化)
• 抽象類別
• STUDENT
• GENERAL_STUDENT
• GRADUATE_STUDENT

抽象類別
• 經常被描述為：不能實體化的類別
• 從概念層次上定義抽象類別
• 把一組相關類別看成一個概念
• 封裝了變化
• 對講師來說，就不需要知道學生是大學還是研究所，因為變化被封裝了

封裝拯救了我們
• 物件對自己行為所負的責任越多，控制程式需要負的責任就越尐
• 封裝使物件內部行為的變化對其他物件變得透明了(不可見)
• 封裝防止了修改程式容易產生的副作用

物件
• 傳統看法
• 具有方法的資料
• 智慧資料
• 只是從實作的視角來看物件而已
• 新看法
• 具有責任的實體
• 責任定義了物件的行為
• 具有特定行為的實體

關注點？
• 關注物件的意圖行為而非實作
• 不要過早操心實作細節

封裝
• 傳統看法：資料隱藏
• 大傘的故事
• 新看法：任何形式的隱藏
• 實作細節
• 衍生類別
• 設計細節
• 實體化規則

發現變化並將其封裝
• 資料的封裝
• 每種動物有不同的腿的數量，利用資料成員將變化封裝
• 方法的封裝
• 每種動物的移動方式不同
• 類型的封裝
• 動物這個抽象類別把各種動物的變化封裝起來了

共通性與可變性分析
• 共通性分析：找出不隨時間而改變的結構
• 可變性分析：找出變化
• 在找到變化之前，一定是先找到共通性

小結
• 很多書都告訴你要使用一些PATTEN來幫助你設計個好的架構，但這些PATTEN的共通性
是什麼？
• 我們應該從起初的設計上就去改變，先從責任的分配來設計，先把細節擺在一邊。
• 去猜測可能的變化在哪，將其封裝起來。

參考資料
• 設計模式的解析與活用（DESIGN PATTERNS EXPLAINED: A NEW PERSPECTIVE
ON OBJECT-ORIENTED DESIGN, 2ND EDITION）

Recommended