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