談設計模式之迷思

很多軟體工程師很希望自己能夠在軟體設計上有所成長，通常第一步都是被推坑設計模式 (或稱設計範式, 原文 Design Pattern) 相關書籍，讀了老半天不知所以然，卻不知這是錯誤的第一步。怎麼說？

筆者認為很多事情都是回歸原點思考，就能夠徹底瞭解。設計範式本身是在軟體實作中演化統整而來，而不是先談空想的方法學，再從實例中一一應用，這就是為什麼很多人說得一口好範式，但卻很難寫出好的類別。也有很多人自己沒有很懂設計範式，就隨便推坑叫人讀設計範式的書籍。

如上面所說的，設計範式是從軟體實作中演化而來，被經驗豐富的程式設計師整理歸納出來，最後變成設計範式的相關書籍。所以，真正要練習設計範式，就應該親手練習撰寫大量代碼，練習設計，並透過使用案例做調整，練習重構重構再重構，並在實務中找到合適的範式做應用。

很多時候，工程師太過於遵循現有規則，以至於只敢使用書中出現過的範式。也有工程師走火入魔只為了套用一個範式而遷就 API 設計。其實，有時候 (或許很少) 依不同場景是需要自己設計新的範式來使用，畢竟範式也是人們發展出來的。

更重要的，是親自參考其他經驗豐富的程式設計師如何設計類別、處理類別之間的資料交換、職權分離等等技巧。

更廣義的說，範式不只是重構的一部份，更也是 API 設計的一部份，所以程式設計師更不該捨本逐末，從範式開始思考。應該是先從需求面思考整個 API 設計開始。

設計樣式的著作，為了要能夠讓讀者很清楚瞭解一個範式是如何被應用，通常使用案例會被過度簡化，案例也太過範例性質，多數都是用 Bank, Account, Car, Door, Factory 等簡單的範例來描述一個問題或者範式的應用，沒有辦法反映真實世界中專案的狀況。在真實世界中，你要處理 Connection timeout, Error, Exception, Naming Convention, Programming Language 本身特性等等，這些都需要大量的經驗跟程式碼閱讀。可惜的是，許多工程師只能讀文件，缺少自行研讀追蹤程式碼的能力，遇到文件沒提到的東西，一下就 Panic 放棄了。

程式碼和文學一樣，需要品味，程式碼可看作是高度組織性且包含邏輯的文章，懂得品味的工程師只需看一份程式碼，便可理解寫這份程式碼的工程師程度為何。閱讀設計範式中的範例，只能算是著作中的例句，甚至只是造句，而光讀造句是沒有辦法學會寫好一篇文章的。

所以，與其讀設計範式的書，何不直接讀 GitHub 上知名專案的開源程式碼呢？