最近上完了 Bill 老師的 Design Pattern 課程，對於 Design Pattern 有了更進一步的體悟。
回想當初我藉由《深入淺出設計模式》一書初次接觸 Design Pattern，看完之後，完全就是「手上有鎚子，看什麼都像釘子」的狀態，實做專案第一個想的就是要套用什麼 Pattern，希望一次把 Pattern 搞對之後就能高枕無憂，也覺得好像套上了 Pattern，一切就感覺高大上了起來。但這完全是錯誤至極的思維，上完這門課之後，對於 Design Pattern 有了更明確的一個輪廓。
簡單來說，Design Pattern 如同一本兵書，裡頭含有各式各樣兵法，然而最最重要的，是各兵法背後為了解決問題的箇中道理，而不在於兵法的樣式。
隨著經驗增長，也慢慢發現這些 Pattern 只是高手「經驗分享」的題庫，即便架構類似，未必在自己的實務上就適合直接套用。面對這些「經驗分享」應該學習它具體是為了解決怎樣的問題，若有一天也遇到類似的問題可以參考。出發點，應該是面對自己專案實際的問題，Pattern 只是輔助。
想想以下這個例子：
要完成一個飲茶推車服務生的服務應用，該服務生要針對不同的客群，提供不一樣的服務。現已知有素食主義者、穆斯林（不吃豬肉）。需求發生異動的部份在於可能出現新的客群，例如不吃牛、不吃海鮮、...等。若絲毫不考慮需求的異動點，單就服務生這行為看起來頗像「Visitor（拜訪者）」的吧！於是乎，就套用 Visitor Pattern（拜訪者模式）啦！
可想而知，若未來出現需求異動，IVisitor、Waiter 都必須修改。最糟的是修改後完全沒有發現這有什麼不對勁，只覺得有需求就改而已啊，絲毫沒有察覺這大大的違反了 Open-Closed Principle（開閉原則）。Visitor Pattern 適用的情境應該是拜訪的對象穩定，可能出現新的拜訪者種類（提供不同的服務）。以這個例子來說，倘若需求異動是發生在可能有其他更多種類的服務生，提供素食主義者及穆斯林這兩種客群更多不同的服務，就適用 Visitor Pattern。
在沒有健全 OOP 基礎的狀況下，貿然套用樣式看起來合適的 Design Pattern，卻沒有發現 Pattern 的關鍵點在於它是想解決怎樣的問題，而不在他的「形狀」。形狀反而是相對無關緊要的一環。
