尋找問題

日前聽到尋找問題，而非答案，並不是很放在心上。
因為印象中類似的說法聽過滿多次了。

不過剛剛在 ptt Java 板看到 AmosYang 所說的（#1A_pc1o8）：

在我的觀念裡，許多人說 OOP 好難懂、 calculous 好難懂、 pointer 好難懂 …
是因為他們還沒有真正遇到需要用到這些工具的問題
一般來說，鑽研工具本身對了解問題的本質並沒有太大的幫助

忽然間回想起自己以前讀 Design Patterns, 真的是每字每句
都看得懂，但全部看過去，不明白為什麼要這樣做，不明白這樣做
能換到什麼，不明白這樣的東西有何價值。

強自去套 pattern, 然後宣稱有 pattern 這種事就別提了。

但後來回過頭再來看時，忽然間就覺得有些作法極其漂亮，
甚至是，有些本來自己就有在用了，只是並沒有給他一個名字，
並沒有把這件事當成一個 pattern 在用，只是一種模糊的概念。

有時候也會覺得，強分這些 pattern 並不是真的很有意義。
例如 template method, factory method, abstract factory,
strategy, state, blah blah, 總覺得概念上其實是相近的，
不需要特別說有這麼多種，也並不是有一個唯一的定義。

或許應該要整理出來的是問題，而非答案。
以答案去尋求問題，似乎本末倒置。

The Hitchhiker's Guide to the Galaxy 裡的最終答案，
找到了答案，卻不知道問題，總覺得也是在嘲諷這種現象。

也許 Monad 也是如此。一直在看 Monad 的定義與作法，
恐怕會迷失掉吧...