如果您陷入了設計模式的僵局，為什麼不使用最實用的編程技巧來拯救自己：重構？
沒有什麼比用錯誤的使用自認為聰明的方式更危險
Image by StartupStockPhotos from Pixabay
好的程序設計的核心原則之一是不要兩次解決相同的問題。 如果有人已經發明瞭完美的泡泡糖，那麼您就不需要自己再做一個了。 如果您有合理的正則表達式來驗證電子郵件地址，則無需自己做。 等等。
這種邏輯很容易理解。 每次您重新設計一項功能時，都有可能會橫盤整理。 您可能會引入新的錯誤，也可能會遇到意想不到的缺點。 充其量，您的代碼將佔用額外的測試時間。 最糟糕的情況是，您會產生隱藏在應用程序接縫中的問題，例如舊床架角落的臭蟲。
因此，很容易理解設計模式的魅力。 如果我們要一遍又一遍地解決相同的問題，我們明智地使用規範的解決方案，這些解決方案是由更聰明的程序員創建的，並且經過了千千萬萬個測試。 或者，換句話說，我們不是有責任使用經過戰鬥考驗的模式來節省時間，並確保最終產品達到最佳狀態嗎？
這就是設計模式吸引您的方式。
設計模式簡史
模式的概念：您可以定義和重用的概念模型， 它根深蒂固，可以追溯到真實的建築（建築物）和Christopher Alexander的工作。 但是大多數程序員都知道的設計模式在1994年問世，當時四位編碼天才寫了一本書，名為《設計模式：可重用的面向對象軟件的元素》。
The book that launched a thousand design reviews
設計模式列出了23種基本模式，分為三類：創造型，結構型和行為型 。 令人驚奇的是，當人們談論當今的設計模式時（大約25年後），他們通常指的是本書最早編纂的一種古老的模式。
這種成功絕非偶然。 不可否認，原始設計模式是由比您本人更敏銳的程序員編寫的。 但是設計模式並不是軟件設計的中性部分，使用它們的代價通常被忽略。
複雜性的代價
設計模式通常與架構類推銷給程序員。 想象您正在建造一個新家。 您是否希望從事這項工作的商人重新發明家用管道系統？ 您想讓電工用自己的方法來組裝保險絲嗎？
A couple of design patterns short of perfection / [Pixabay]
但是構建軟件系統與構建房屋有很大不同。 一方面，設計模式不是您可以直接放入代碼中的要素，就像類庫中的便捷函數一樣。 相反，每個模式都是需要實現的模型。 大多數設計模式都定義了跨越不同對象的交互，這意味著您需要對多個類進行更改。 此額外代碼的絕對分量使您的設計複雜化。 對於新開發人員來說，它們尤其危險，因為他們從未見過自己不想做的編碼評審。
即使設計模式處於最佳狀態，它們也會迫使您將簡單性換成其他東西。 通常，"其他"僅僅是對良好封裝的模糊承諾。
The general problem / XKCD
設計模式是固執己見的。 他們將自己嵌入到您的代碼中，並向特定的方向拉動您的類。
即使是最簡單的模式也要付出代價，並會帶來複雜性。 考慮簡單的的Singleton模式-一個僅允許一個實例的類。 儘管從概念上講它很簡單，但是根據您需要線程安全性，延遲加載，可序列化性，對繼承的支持還是隻喜歡枚舉，大約有十二種不同的實現Singleton模式的技術。
並不是說Singleton設計是一個高級概念。 不可能將任何單一代碼成分設計成完全通用化並完全適合每個用例。 直到今天，架構師仍在爭論Singleton是一種優質的鍍金模式還是一種反模式-您應努力避免這種情況，因為總有一天它會背叛您。
模稜兩可的可擴展性
設計模式都是關於增加代碼中的抽象性的。 諸如Proxy，Bridge，Adapter和Facade之類的模式會在對象之間添加層。 起初，這似乎是編程的天堂。 哪個賢惠的程序員不希望對象之間的依賴性降低？
我們都知道規則：計算機科學中的所有問題都可以通過另一層間接解決。 但是也有副作用。 間接的每一額外層都會添加一個新的東西，您可以在其中放置一個解決方案。
換句話說，您對設計進行抽象化的方式越多，您打開的空間就越多，可以供其他人更改代碼。 未來的程序員將很難弄清楚要修改系統的哪個部分，以及如何擴展代碼而又不會使工作與其他人的更改發生衝突。
最嚴重的違法者是中介者模式，該模式旨在讓兩個對象相互作用而不相互瞭解。 結果要麼是神聖的抽象必殺技，要麼是嚴重混淆類模型中責任的方法。
有兩種方法可以破壞汽車：1）砸碎汽車。 2）將其稱為通用道路限制運輸容器，然後開始添加它。
不匹配和不合適
在不瞭解上下文的情況下很容易著手實施模式，換句話說，這些模式如何適合您選擇的語言，框架和應用程序類型？
答案可能很模糊。 諸如泛型之類的現代語言功能改變了模式的使用方式。 就像Peter Norvig所言，從Lisp到Python的動態語言使許多模式變得過時了。 函數式編程語言以完全不同的模式存在於並行世界中。
這些不一致不僅限於語言功能。 其他模式不適用於某些類型的基礎架構。 例如，如果您正在處理網絡協議，則不需要chatty對象，而多線程代碼可能會破壞大多數原始23種設計模式的標準實現。
模式在框架設計者手中處於最佳狀態，他們可以將其直接集成到框架中。 例如，事件是觀察者模式的現代示例。 原型模式已融合到JavaScript（及其所有面向對象功能的來源）中。 像ASP.NET這樣的服務器端Web框架實現了傳奇的Model View Controller模式。 等等。
解藥：簡單
如果設計模式很危險，那麼解決方案是什麼？ 答案是採取簡單莊嚴的保證。 這是編程世界的一種希波克拉底誓言：
首先，要簡單。
如果您深陷棘手的問題，在分號和類關係的迷霧中，請嘗試解除責任並保持一切可管理。 不要讓設計模式影響您的批判性思維。 畢竟，擁有模式並不能保護您免受不良設計的影響。 無法保證您認為要解決的問題是您真正需要解決的問題。 而且，添加無法解決的問題（或根本沒有問題）的模式是通往軟件維護地獄的必經之路。
如果您不能保證程序的其他功能，請保證使其簡單。
Standards / XKCD
模式是一種設計語言
設計模式的真正價值不是規定性的（告訴您要做什麼）而是描述性的（告訴別人您所做的事情）。 設計模式不是配方。 他們是一種語言。
當您將設計模式視為可以幫助您討論應用程序設計的語言時，就會發生好事。 您無需開始嘗試使用模式。 取而代之的是，隨著經驗的積累，您將開始認識到在代碼中明確形成的模式的輪廓。 例如，如果您對Web服務進行編碼，則幾乎可以肯定地使用Facade模式，無論您是否識別出它。 認識到代碼的新興結構後，您就可以使用設計模式的語言（如工廠，裝飾器和門面等概念）來形式化您所做的工作。
設計模式無法教您軟件架構。 它們並不是寫大量代碼的藉口，也不是避免深入考慮設計的一種方法。 但是它們可以幫助您以更高的抽象水平思考設計。 那可能就是四人幫一直希望的。
（本文翻譯自Matthew MacDonald的文章《Is It Time to Get Over Design Patterns?》）
閱讀更多 聞數起舞 的文章
