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