設計異味

設計異味是計算機編程領域，設計所用結構違背了基本設計原則並對設計質量有負面影響。^[1]這個術語源自馬丁·福勒在《重構-改善既有代碼的設計》一書中描述的代碼異味。^[2]

不同作者對「異味」（smell）有不同的定義：

• N. Moha等：「代碼與設計異味是差的解決方案，導致了實現與設計問題」^[3]
• R. C. Martin：「設計異味是腐敗的軟件的氣味」^[4]
• Fowler：「異味是代碼中特定的結構導致了重構的可能」^[2]

設計異味指示了積累的設計負債（技術負債的主要維度）。Bug與未實現功能不算是設計異味。設計異味產生於很差的設計決策，使得設計脆弱、難於維護。在一個軟件系統中辨別設計異味，應用適當的重構去除異味，避免積累技術負債，是好的實踐。

在確定特定結構或決策是否算作設計異味時，上下文環境（如問題清單、設計生態圈、平台等）扮演了重要角色。很多時候，由於上下文環境所限，只好容忍設計異味。

常見設計異味

• 缺乏抽象（Missing abstraction）^[1]，如果使用數據泥團而不是創建抽象。也稱作基本類型迷戀 ^[2]、數據泥團（data clumps）。^[2]。
• 多方面的抽象（Multifaceted abstraction）^[1]，如果一個抽象有多重責任。也稱作概念化的濫用^[5]
• 重複的抽象（Duplicate abstraction）^[1]，如果兩個或多個抽象有相同的名字或實現。也稱作不同接口的可選類^[2]、重複的設計品。^[6]
• 缺乏封裝（Deficient encapsulation）^[1]，如果一個抽象的一個或多個成員的被聲明的可訪問性超出了實際需要。
• 未利用的封裝（Unexploited encapsulation）^[1]，如果客戶代碼使用顯式類型檢查（使用鏈式if-else或switch語句檢查對象的類型）而不是雷雨封裝在架構中的類型的變化。
• 破損的模塊化（Broken modularization）^[1]，如果數據與/或方法本應在一個抽象中，卻被分開放到了不同的抽象中。
• 不充分的模塊化（Insufficient modularization）^[1]，如果一個抽象實際上還沒有被徹底分解，如果進一步分解會減小其尺寸或實現複雜度。
• 循環依賴的模塊化（Cyclically-dependent modularization）^[1]，如果兩個或多個抽象直接或間接互相依賴（抽象之間緊耦合）。也稱作循環依賴。^[7]
• 未分解的架構（Unfactored hierarchy）^[1]，如果架構內部存在不必要的重複的類型
• 破損的架構（Broken hierarchy）^[1]，如果一個父類型與一個子類型概念上並不構成「IS-A」關係，這導致了替代性的破缺。也稱作「繼承的不當使用」^[8]、無用「IS-A」^[9]。
• 循環的架構（Cyclic hierarchy）^[1]，如果父類型依賴於它的某個子類型。也稱作繼承/引用循環^[10]。
• 僵化（Rigidity）：系統難以修改，因為每個改變迫使系統其他部分也要做出修改。
• 脆弱（Fragility）：一個修改可能引發沒有概念關係的其他地方的崩潰。
• 頑固（Immobility）：很難把系統分離為可被其他系統重用的模塊
• 粘滯（Viscosity）：做正確的事比做錯事更難。
• 不必要的複雜（Needless Complexity）：設計包含了沒有直接好處的基礎設施。
• 不必要的重複（Needless Complexity）：設計包含了本可以用一個抽象統一起來的重複的結構。
• 晦澀（Opacity）：難以閱讀與理解。不能很好的表達其意圖。

面向對象設計的有助於消除異味的原則

面向對象設計的SOLID五大原則： 單一功能原則：一個類只應有一個「改變的原因」（即功能）； 開閉原則：軟件實體（類、模塊、函數等）應當對擴展是開放的，對修改是關閉的； 里氏替換原則：子類型能替換基類型； 依賴反轉原則：高層模塊不應依賴於低層模塊，二者應當依賴於抽象。抽象不應依賴與細節。細節應當依賴於抽象。 接口隔離原則：類應當有胖（fat）接口，可被分為方法的分組。每個分組服務於不同的客戶集。客戶不應當知道這些分組是在同一個類中。

參見

• 代碼異味
• 反模式
• 軟件腐爛（英語：Software rot）
• 技術負債