設計模式和反模式簡單介紹

作為一個資深開發人員，大家都應該聽說過設計模式(design pattern)，但是不是所有的人都聽說過反模式(anti-pattern)。今天我們就來談談後者，何為反模式。

談反模式之前當然先要談談何為設計模式，因為兩者是緊密聯絡在一起的。從我個人的理解認為，設計模式是一種在前人的設計經驗上總結出來的對於一些普遍存在的問題提供的通用的解決方案。這些設計模式已經經過了長時間的實際應用和驗證，被證實是有效可行的解決方案。透過使用設計模式，我們可以獲得以下優勢：

1.       開發小組不需要重新設計解決方案來解決已經被前人解決過的問題。如此可以節省很多設計開發時間。

2.       當開發小組討論設計的時候，使用設計模式可以使大家更好了理解問題所在和解決方案，而且對解決方案有一個比較統一的認知。

3.       設計模式本身已經透過了大量的實際運用和驗證，其設計質量和實用價值有很好的保證。

4.       設計模式本身有健全的文件，可以一定程度上簡化撰寫開發文件。

在開發過程中，使用設計模式對系統/軟體開發有很多其他的優點，這裡就不一一列舉了。一些常用的設計模式包括：單列模式， 工廠模式， 修飾模式， 策略模式， 代理模式等等。有興趣的朋友可以看下 “四人幫” 的 設計模式這本書 “Design Patterns: Elements of Reusable Object-Oriented Software”， 其他還有大量討論設計模式的書籍， 比如 “Head First Design Pattern”,  “The Design Patterns Java Workbook” 等等。

簡單的談完了設計模式，我們來談一下重點，什麼是反模式。很多人對反模式有一個理解誤區，有人認為反模式是由於將通常使用的設計模式用在了錯誤的地方，也有人認為反模式只是一種壞習慣。簡單的來說，反模式是指在對經常面對的問題經常使用的低效，不良，或者有待最佳化的設計模式/方法。甚至，反模式也可以是一種錯誤的開發思想/理念。在這裡我舉一個最簡單的例子：在物件導向設計/程式設計中，有一條很重要的原則， 單一責任原則(Single responsibility principle)。其中心思想就是對於一個模組，或者一個類來說，這個模組或者這個類應該只對系統/軟體的一個功能負責，而且該責任應該被該類完全封裝起來。當開發人員需要修改系統的某個功能，這個模組/類是最主要的修改地方。相對應的一個反模式就是上帝類(God Class)，通常來說，這個類裡面控制了很多其他的類，同時也依賴其他很多類。整個類不光負責自己的主要單一功能，而且還負責了其他很多功能，包括一些輔助功能。很多維護老程式的開發人員們可能都遇過這種類，一個類裡有幾千行的程式碼，有很多功能，但是責任不明確單一。單元測試程式也變複雜無比。維護/修改這個類的時間要遠遠超出其他類的時間。很多時候，形成這種情況並不是開發人員故意的。很多情況下主要是由於隨著系統的年限，需求的變化，專案的資源壓力，專案組人員流動，系統結構的變化而導致某些原先小型的，符合單一原則類慢慢的變的臃腫起來。最後當這個類變成了維護的噩夢(特別是原先熟悉的開發人員離職後)，重構該類就變成了一個不容易的工程。

同設計模式一樣，也有不少的書籍討論反模式，比如 “AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis”， “Antipatterns: Identification, Refactoring, and Management”， “J2EE AntiPatterns”，對設計模式和反模式感興趣的朋友們有空可以讀一下。