In
computer programming
Computer programming is the process of performing a particular computation (or more generally, accomplishing a specific computing result), usually by designing and building an executable computer program. Programming involves tasks such as anal ...
, design smells are "structures in the design that indicate violation of fundamental design principles and negatively impact design quality".
[Girish Suryanarayana, Ganesh SG, Tushar Sharma (2014). "Refactoring for software design smells: Managing technical debt". Morgan Kaufmann. ] The origin of the term "design smell" can be traced to the term "
code smell
In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development meth ...
" which was featured in the book ''Refactoring: Improving the Design of Existing Code'' by
Martin Fowler.
[Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. .]
Details
Different authors have defined the word "smell" in different ways:
* N. Moha ''et al.'': "Code and design smells are poor solutions to recurring implementation and design problems."
[N. Moha, Y. Gueheneuc, L. Duchien, and A. Le Meur. "Decor: A method for the specification and detection of code and design smells". IEEE Trans. Softw. Eng., 36(1):20–36, January 2010.]
* R. C. Martin: "Design smells are the odors of rotting software."
[R. C. Martin. ''Agile Software Development, Principles, Patterns, and Practices''. Addison-Wesley, 2003.]
* Fowler: "Smells are certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring."
Design smells indicate the accumulated
design debt (one of the prominent dimensions of
technical debt
In software development, technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.
Analogous with ...
). Bugs or unimplemented features are not accounted as design smells. Design smells arise from the poor
design
A design is a plan or specification for the construction of an object or system or for the implementation of an activity or process or the result of that plan or specification in the form of a prototype, product, or process. The verb ''to design' ...
decisions that make the design fragile and difficult to maintain. It is a good practice to identify design smells in a software system and apply appropriate refactoring to eliminate it to avoid accumulation of technical debt.
The context (characterized by various factors such as the problem at hand, design eco-system, and platform) plays an important role to decide whether a certain structure or decision should be considered as a design smell. Generally, it is appropriate to live with design smells due to constraints imposed by the context. Nevertheless design smells should be tracked and managed as technical debt because they degrade the overall system quality over time.
Common design smells
* Missing abstraction
when clumps of data or encoded strings are used instead of creating an abstraction. Also known as "primitive obsession"
and "data clumps".
* Multifaceted abstraction
when an abstraction has multiple responsibilities assigned to it. Also known as "conceptualization abuse".
* Duplicate abstraction
when two or more abstractions have identical names or implementation or both. Also known as "alternative classes with different interfaces"
and "duplicate design artifacts".
* Deficient encapsulation
when the declared accessibility of one or more members of an abstraction is more permissive than actually required.
* Unexploited encapsulation
when client code uses explicit type checks (using chained if-else or switch statements that check for the type of the object) instead of exploiting the variation in types already encapsulated within a hierarchy.
* Broken modularization
when data and/or methods that ideally should have been localized into a single abstraction are separated and spread across multiple abstractions.
* Insufficient modularization
when an abstraction exists that has not been completely decomposed, and a further decomposition could reduce its size, implementation complexity, or both.
*
Circular dependency
In software engineering, a circular dependency is a relation between two or more modules which either directly or indirectly depend on each other to function properly. Such modules are also known as mutually recursive.
Overview
Circular depend ...
. Cyclically-dependent modularization
when two or more abstractions depend on each other directly or indirectly (creating a tight coupling between the abstractions). Also known as "cyclic dependencies". Cyclic hierarchy
when a supertype in a hierarchy depends on any of its subtypes. Also known as "inheritance/reference cycles".
* Unfactored hierarchy
when there is unnecessary
duplication
Duplication, duplicate, and duplicator may refer to:
Biology and genetics
* Gene duplication, a process which can result in free mutation
* Chromosomal duplication, which can cause Bloom and Rett syndrome
* Polyploidy, a phenomenon also known ...
among types in a hierarchy.
* Broken hierarchy
when a supertype and its subtype conceptually do not share an “IS-A” relationship resulting in broken substitutability. Also known as "inappropriate use of inheritance" and "misapplying IS A".
[Page-Jones M. "Fundamentals of object-oriented design in UML". Addison-Wesley Professional; 1999.]
See also
*
Anti-pattern
An anti-pattern in software engineering, project management, and business processes is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by computer programmer An ...
*
Software rot
Software rot (bit rot, code rot, software erosion, software decay, or software entropy) is either a slow deterioration of software quality over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusabl ...
References
{{reflist
Computer programming folklore
Software engineering folklore