l

2014年6月30日 星期一

套用Pattern之前先確定它要解決什麼問題

June 29 20:40~21:36

螢幕截圖 2014-06-29 21.35.36

 

幾年前Teddy有一次跟指導教授聊天,當時指導教授正在研究Michael Jackson的《Problem Frames》。指導教授提到:「Michael Jackson在他的書中有提到Patterns,他認為Patterns最大的問題就是只關注解決方案(solution),沒有提到問題(problem)。」當時Teddy不明白這句話的意思,Alexander的Pattern,明明有包含Name、Context、Problem、Force、Solution、Resulting Context這六大元素,怎麼會沒有提到問題?

多年來指導教授多次誘導Teddy去閱讀Michael Jackson的《Problem Frames》,無奈讀了幾次都沒辦法領悟,也就暫時放下。後來有一陣子Teddy想把GoF的23個Design Patterns用Name、Context、Problem、Force、Solution、Resulting Context的格式重新整理,此時才發現,還真的無法一眼就看出這23個Design Patterns到底要解決什麼「問題」。

鄉民甲:GoF的每一個Design Patterns不是都有Intent這個欄位嗎?很多書都是透過Intent來介紹每一個Design Pattern。

Teddy:是這樣沒錯,但如果你仔細去看每一個Design Pattern的Intent,其實比較像是簡短的解決方案說明,而不是該設計模式要解決的問題。

***

今年六月的第七梯次「Design Patterns這樣學就會了:入門實作班」有學員問Teddy幾個問題:

  • 權限管理系統可否套用State?
  • Adapter和Facade有何不同 ?
  • State和Strategy有何不同 ?

以上這四個問題,以及其他更多在套用或比較不同Pattern差異時所遭遇到的困難,其根本原因,都可以說是「對每一個Pattern所要解決的問題了解得不夠徹底。」如果可以清楚說出每一個Pattern所要解決的問題,就可判斷上述四個問題的答案:

  • State要解決的問題是「當物件內部狀態改變時,你要如何讓它的行為也跟著改變,就好像這個物件換了另外一個人似的?」請問權限管理系統是否要解決相同的問題?
  • Adapter要解決的問題是「如何重複使用一個既存的類別?」,Facade要解決的問題是「 如何使用子系統?」
  • State要解決的問題是「當物件內部狀態改變時,你要如何讓它的行為也跟著改變,就好像這個物件換了另外一個人似的?」,Strategy要解決的問題是「如何讓物件切換行為實作?」

***

從pattern的解決方案,光是看class diagram,會覺得許多pattern都很相似。從問題出發,加上force與context,就可以清楚的區分每一個pattern的差異。

***

友藏內心獨白:Michael Jackson的Problem和Pattern的Problem是不一樣的挑眉質疑

3 則留言:

  1. 這...我有點驚訝...難道很多用pattern的人都不思考適用性就套用嗎?這是需要強調的事情?

    回覆刪除
  2. 我相信,有些使用者是因為書上的故事類似就套用了

    回覆刪除
  3. 就跟有些人Google Stackoverflow後就沒改太多直接把程式碼搬過去,真的有RD這麼幹,我遇過= =

    回覆刪除