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

June 29 20:40~21: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是不一樣的。