设计异味

设计异味是计算机编程领域，设计所用结构违背了基本设计原则并对设计质量有负面影响。这个术语源自马丁·福勒在《重构-改善既有代码的设计》一书中描述的代码异味。

不同作者对“异味”（smell）有不同的定义：

• N. Moha等：“代码与设计异味是差的解决方案，导致了实现与设计问题”
• R. C. Martin：“设计异味是腐败的软件的气味”
• Fowler：“异味是代码中特定的结构导致了重构的可能”

设计异味指示了积累的设计负债（技术负债的主要维度）。Bug与未实现功能不算是设计异味。设计异味产生于很差的设计决策，使得设计脆弱、难于维护。在一个软件系统中辨别设计异味，应用适当的重构去除异味，避免积累技术负债，是好的实践。

在确定特定结构或决策是否算作设计异味时，上下文环境（如问题清单、设计生态圈、平台等）扮演了重要角色。很多时候，由于上下文环境所限，只好容忍设计异味。

常见设计异味

• 缺乏抽象（Missing abstraction），如果使用数据泥团而不是创建抽象。也称作基本类型迷恋 、数据泥团（data clumps）。。
• 多方面的抽象（Multifaceted abstraction），如果一个抽象有多重责任。也称作概念化的滥用
• 重复的抽象（Duplicate abstraction），如果两个或多个抽象有相同的名字或实现。也称作不同接口的可选类、重复的设计品。
• 缺乏封装（Deficient encapsulation），如果一个抽象的一个或多个成员的被声明的可访问性超出了实际需要。
• 未利用的封装（Unexploited encapsulation），如果客户代码使用显式类型检查（使用链式if-else或switch语句检查对象的类型）而不是雷雨封装在架构中的类型的变化。
• 破损的模块化（Broken modularization），如果数据与/或方法本应在一个抽象中，却被分开放到了不同的抽象中。
• 不充分的模块化（Insufficient modularization），如果一个抽象实际上还没有被彻底分解，如果进一步分解会减小其尺寸或实现复杂度。
• 循环依赖的模块化（Cyclically-dependent modularization），如果两个或多个抽象直接或间接互相依赖（抽象之间紧耦合）。也称作循环依赖。
• 未分解的架构（Unfactored hierarchy），如果架构内部存在不必要的重复的类型
• 破损的架构（Broken hierarchy），如果一个父类型与一个子类型概念上并不构成“IS-A”关系，这导致了替代性的破缺。也称作“继承的不当使用”、无用“IS-A”。
• 循环的架构（Cyclic hierarchy），如果父类型依赖于它的某个子类型。也称作继承/引用循环。
• 僵化（Rigidity）：系统难以修改，因为每个改变迫使系统其他部分也要做出修改。
• 脆弱（Fragility）：一个修改可能引发没有概念关系的其他地方的崩溃。
• 顽固（Immobility）：很难把系统分离为可被其他系统重用的模块
• 粘滞（Viscosity）：做正确的事比做错事更难。
• 不必要的复杂（Needless Complexity）：设计包含了没有直接好处的基础设施。
• 不必要的重复（Needless Complexity）：设计包含了本可以用一个抽象统一起来的重复的结构。
• 晦涩（Opacity）：难以阅读与理解。不能很好的表达其意图。

面向对象设计的有助于消除异味的原则

面向对象设计的SOLID五大原则： 单一功能原则：一个类只应有一个“改变的原因”（即功能）； 开闭原则：软件实体（类、模块、函数等）应当对扩展是开放的，对修改是关闭的； 里氏替换原则：子类型能替换基类型； 依赖反转原则：高层模块不应依赖于低层模块，二者应当依赖于抽象。抽象不应依赖与细节。细节应当依赖于抽象。 接口隔离原则：类应当有胖（fat）接口，可被分为方法的分组。每个分组服务于不同的客户集。客户不应当知道这些分组是在同一个类中。

参见

• 代码异味
• 反模式
• 软件腐烂
• 技术负债