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

作為一個資深開發人員，大家都應該聽說過設計模式(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)，通常來說，這個類里面控制了很多其他的類，同時也依賴其他很多類。整個類不光負責自己的主要單一功能，而且還負責了其他很多功能，包括一些輔助功能。很多維護老程序的開發人員們可能都遇過這種類，一個類里有幾千行的代碼，有很多功能，但是責任不明確單一。單元測試程序也變復雜無比。維護/修改這個類的時間要遠遠超出其他類的時間。很多時候，形成這種情況并不是開發人員故意的。很多情況下主要是由于隨著系統的年限，需求的變化，項目的資源壓力，項目組人員流動，系統結構的變化而導致某些原先小型的，符合單一原則類慢慢的變的臃腫起來。最后當這個類變成了維護的噩夢(特別是原先熟悉的開發人員離職后)，重構該類就變成了一個不容易的工程。

作者華杰， 從事IT工作15年，做過程序員，首席軟件工程師，架構師，IT技術顧問，現為澳大利亞移民和邊境保護局Tech lead.