或許有些東西說的比較主觀，有些細節點說的不到位，但我覺得當你真正發現并領悟所有的設計架構都是圍繞業務服務和后期維護考慮時，過度設計的問題大體上就解決了。

引言

設計模式被認為是軟件設計的“規范”，但是在互聯網快速發展的過程中，也暴露了一些問題。相比過程式代碼的簡單與易于修改，設計模式常常導致代碼復雜，增加理解與修改的成本，我們稱之為 “過度設計”。

(資料圖片僅供參考)

過度設計是認知提升過程中的必經階段，用什么語言都一樣。一般情況下，我們跟著公司內部的開發規范走，就能在寫代碼的時候避免大部分坑點，減少代碼故障和設計缺陷，但這也無法完全解決過度設計的問題，那么過度設計是怎么產生的，又需要怎么減少呢？

本文將探索以下問題：

1.為什么要做代碼設計

我認為做代碼設計的根本原因只有一個：提高代碼質量；

而代碼質量的提升怎么體現出來呢？兩個方面：1、讓代碼讀起來更容易；2、讓代碼寫起來更簡便。

1.1 讓代碼讀起來更容易

首先，對于一個程序員來說，我們既要開發自己的項目，也會維護別人交接過來的項目。我們接手的代碼風格各式各樣，理解成本也各不相同。

不否認一些同學技術能力非常出眾，理解能力超群，什么樣的代碼都能讀懂，并能很快的在其基礎上進行優化、開發、重構。但對于絕大多數心態平和的同學而言，接手一個 設計凌亂，無標準開發規范 的項目絕對能讓其心態崩潰甚至開發時滿嘴臟話。我們開發時遵守的“編碼規范”、“設計規范”，無一不是在為了讓項目更好理解，更好維護。

舉幾個例子：編碼的分層、分模塊，對象和接口設計時的單一職責原則、開閉原則、策略模式等，都能讓我們的項目更有層級，更好理解其結構，讓代碼讀起來更容易。

1.2 讓代碼寫起來更簡單

說到讓代碼寫起來更簡單，就不得不說到代碼的復用。如果代碼不復用，每增加一個需求就只能往上堆代碼，寫的代碼越來越多，代碼風格與功能就不會呈收斂態。

那么怎么能使代碼更簡單呢？

盡量相同的功能不寫第二遍，抽對象相同屬性走繼承、抽相同方法做工具類、抽象類；按模塊抽、根據路由條件抽、橫著抽、豎著抽，總之代碼復用性越高，寫的代碼就越少。但我們又不能不按條理抽，因為這樣會影響代碼的可讀性也會使依賴變得復雜，這時候設計模式就登場了，先輩們經過多年的代碼設計經驗總結了一些常用代碼的寫法，用于解決 不同場景下如何能將代碼在有條理的條件下寫的更“偷懶” 的問題。（這里只是舉例，并不是說這些模式就是全部的，也不代表這些就是最好的）。

創建型模式：工廠方法模式、抽象工廠模式、單例模式、建造者模式、原型模式。結構型模式：適配器模式、代理模式、橋接模式、裝飾器模式、外觀模式、享元模式、組合模式。行為型模式：策略模式、模板方法模式、觀察者模式、迭代子模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。

學習這些東西能讓我們的代碼復用性更高，擴展起來更容易，也會讓我們代碼看起來高端、大氣上檔次。

簡單介紹幾種設計模式

換個角度看到設計模式

讓我們換個角度來看上面這些設計模式，如果我們將接口的實現方法當做對象類的屬性，

適配器模式是否就成了一個適用于 class 類的工廠模式；工廠模式通過不同的屬性參數創建不同的對象；

適配器模式通過不同的場景創建不同的接口實現類，甚至更向上抽象一層，策略模式通過不同的業務條件路由到不同的接口實現時也有些同樣的味道。

我想說的是不同的設計好多時候他們的基本思考方式是相通的，它們只是一些問題的常用解決方法模板，并不是各不相同的死定義。

2.設計模式是如何衍生出來的

上面說了那么多因為所以，大家可能看文字看的頭痛，這里我先舉例來說明下常規代碼接口設計的發展形式：

產品說我要做個天體系統，先來個月亮

需求一：要有功能：創建個月亮（新產品，產品功能可能給不明確，方向也不明確，先簡單實現其功能）

一月后，再來個地球

需求二：要有功能創建一個月亮，一個地球（有兩個星球了，后續可能會有多個，抽象星球父對象，將相同的東西放父類中）

再一月后，要上星球管理系統了

需求 3：星球創建的時候要加過程，創建地球的時候要順便在星球上造山川、河流，還都要通知到星球管理局（針對不同星球有差異化需求了，考慮到現在星球還只有兩種，段時間內也不會增加特別多，結合開發時間，將星球類當做適配器來用，同時使用模板方法模式將特異性方法抽取成公共方法）

再一年后，要豐富星系了

需求 4：一次創建一個星球，要支持太陽系的 8 種行星，并且之后會擴展為無數種星球，除了地球外初始化的數據和月亮一樣（由于星球數大量擴張，再用 java 類來定義星球需要大量創建 java 類，而且之后要支持無數種星球，現有模式要被打破了，但現階段稍微改改還能平滑過度，結合星球擁有的公共屬性方法，將其合為一個類，先對地球做特殊處理，等要無限支持的時候，做成數據庫配置或者配置中心配置實現）

再一月后：完善產品，支持無限種星球

需求 5：需要支持無限種星球了，可以創建的星球需要由運營去配置，而且創建后需要按照順序分別執行不同的動作，現定義 3 種動作，將來還可能支持更多種動作，動作 1：初始化初始化物體，具體是什么可以由運營配置；動作 2：通知星球管理局；動作 3：遭到撞擊，毀滅；（到處都要支持配置，開放度太高，由于每種星球的差異化需求，之前的星球模型的模板方法明顯已經不支持現有的場景了，需要用一種可以通過配置來執行方法的模型，這里 DemoService 類在一張圖里截不完了，和場景 4 的完全一樣，就先省去吧）

上述過程是一個功能從簡單到復雜，然后使用的設計模式也逐漸改變，最終適用于業務發展的一種過程，如果在需求 1 的時候直接就上需求 5 的責任鏈模式，那么這個就屬于設計過度了。

關于設計過度不同同學往往有不同的容忍度，有時候在某種情況下也可能會成為有前瞻性的設計，關于這塊有時候還是不好評判的。

3.過度設計的的常見形式

什么叫過度設計?

只要團隊里內沒有足夠能力把控未來三年的架構發展，便只需要把代碼重構到恰好滿足當下的最佳狀態，那么我們在開發的時候總是要考慮一下未來的需求到底會往哪個方向走。你蒙中了，就叫正交分解。你沒蒙中，就叫過度設計。

過度設計的場景很多，這里列舉下常見的幾種情況：

有時相同的功能使用不同的設計模式都可以實現，設計模式的引入常常導致代碼復雜，增加理解與修改的成本，我們作為開發者必須要把控理解成本、代碼實現復雜度、減少的代碼量，代碼擴展性之間的平衡，一旦思考不到位、理解不到位，打破了其中的平衡，過度設計就產生了。

而我們在日常學習和開發中，甚至在發或者技術方案評審的時候也不可能開對技術、業務全部理解到位，即使對自己負責的項目理解到位了也沒有條件對跨項目協作中的直接或間接依賴項目的來龍去脈完全清楚，這時候當你想搞個“高級”東西的時候，就很難把控會不會搞出過度設計，這也就是我說的過度設計是認知提升過程中的必經階段。

4.如何避免過度設計

上面說了過度設計的來龍去脈和很難避免性，那么如何能最大限度的避免過度設計呢？

根據我過往經驗大概從這幾個方面著手：

5.總結

上面或許有些東西說的比較主觀，有些細節點說的不到位，但我覺得當你真正發現并領悟所有的設計架構都是圍繞業務服務和后期維護考慮時，過度設計的問題大體上就解決了。

以上是我對于過度設計的理解，隨著我工作年限的增加說不定過兩年我會再有其他感悟，到時候再分享給大家。

關鍵詞：

責任編輯：Rex_09