設計模式濫用的例子

Question

設計模式很好，因爲它們將一種潛在複雜的技術提煉成了一些習慣用法。通常它的名字有助於溝通和理解。

不利之處在於，它可以更容易地嘗試將它們用作銀彈，將它們應用於每種情況，而不用考慮它們背後的動機，並花點時間考慮給定模式是否真的適合情況。

不像this question，我不是在尋找設計圖案，往往誤用，但我很樂意看到的真正堅實的設計模式放到不好用一些例子。我正在尋找某些人「錯過了這個觀點」，或者應用了錯誤的模式，甚至是糟糕的實施。

這樣做的一點是，我希望能夠突出設計模式是不禁止的批判性分析的藉口。另外，我想強調需要了解不只是模式是什麼，但爲什麼他們往往是一個不錯的辦法。

Answer 1

我有一個應用程序，我堅持使用供應商模式幾乎所有 - 很少需要。多層次的繼承。作爲一個例子，有一個數據提供者接口由抽象的BaseDataProvider實現，然後由SqlDataProvider擴展。在每個層次中，每種類型只有一個具體的實現。顯然，開發人員獲得了關於實施企業架構的Microsoft文檔，並且由於許多人使用此應用程序，因此決定需要所有靈活性來支持多個數據庫，多個企業目錄和多個壓光系統，即使我們只使用MS SQL Server ，Active Directory和Exchange。

最糟糕的是全部脫落，像憑證，URL和路徑配置項是硬編碼的所有的地方並覆蓋經由參數傳遞到更抽象類的數據。改變這個應用程序就像拉一件毛衣上的線。你越拉越多的東西得到解決，你最終在整個代碼做了一些本應該很簡單的事情。

我慢慢改寫了 - 部分是因爲該代碼是可怕的，部分是因爲它是真正三個應用程序彙總到一個，是不是真的需要，即使其中一個。

Answer 2

那麼，分享一下體驗吧。在C＃中，我有一個非常酷的設計，它使用了很多模式。我真的使用了很多它們來簡化故事，我不會將它全部命名。但是，當我用真實數據進行實際測試時，10^6個物體沒有用我漂亮的設計「流暢地運行」。通過分析，我剛剛看到所有那些好的多態性類，代理等間接級別太多了..所以我想我可以用更好的模式重寫它，使其更有效，但我沒有時間，所以我幾乎是在程序上對它進行了黑客入侵，直到現在，好吧，它的工作方式會更好......感嘆，悲傷的故事。

Answer 3

我已經看到了一個asp.net應用程序，其中（當時的初級，現在很有能力）開發人員設法有效地使他的代碼隱藏單身人士認爲每個頁面是獨特的，在他的本地機器上出色地工作，直到測試人員正在爲控制登錄屏幕而戰。

純屬的「獨特的」和一記急於使用這些設計模式一樣的東西範圍的誤解。