Design smell

Last updated

In computer programming, a design smell is a structure in a design that indicates a violation of fundamental design principles, and which can negatively impact the project's quality. [1] The origin of the term can be traced to the term "code smell" which was featured in the book Refactoring: Improving the Design of Existing Code by Martin Fowler. [2]

Contents

Details

Different authors have defined the word "smell" in different ways:

Design smells indicate the accumulated design debt (one of the prominent dimensions of technical debt). Bugs or unimplemented features are not accounted as design smells. Design smells arise from the poor 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

See also

Related Research Articles

<span class="mw-page-title-main">Martin Fowler (software engineer)</span> American software developer, author and public speaker

Martin Fowler is a British software developer, author and international public speaker on software development, specialising in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming.

In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

In computer programming, the strategy pattern is a behavioral software design pattern that enables selecting an algorithm at runtime. Instead of implementing a single algorithm directly, code receives run-time instructions as to which in a family of algorithms to use.

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

Software design is the process of conceptualizing how a software system will work before it is implemented or modified. Software design also refers to the direct result of the design process – the concepts of how the software will work which consists of both design documentation and undocumented concepts.

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 methodology.

<span class="mw-page-title-main">Liskov substitution principle</span> Object-oriented programming principle

The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called strong behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address titled Data abstraction and hierarchy. It is based on the concept of "substitutability" – a principle in object-oriented programming stating that an object may be replaced by a sub-object without breaking the program. It is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. Barbara Liskov and Jeannette Wing described the principle succinctly in a 1994 paper as follows:

Subtype Requirement: Let be a property provable about objects of type T. Then should be true for objects of type S where S is a subtype of T.

In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans, and combinations of these. Some computer hardware devices, such as a touchscreen, can both send and receive data through the interface, while others such as a mouse or microphone may only provide an interface to send data to a given system.

Modular programming is a software design technique that emphasizes separating the functionality of a program into independent, interchangeable modules, such that each contains everything necessary to execute only one aspect of the desired functionality.

<span class="mw-page-title-main">Factory (object-oriented programming)</span> Object that creates other objects

In object-oriented programming, a factory is an object for creating other objects; formally, it is a function or method that returns objects of a varying prototype or class from some method call, which is assumed to be "new". More broadly, a subroutine that returns a "new" object may be referred to as a "factory", as in factory method or factory function. The factory pattern is the basis for a number of related software design patterns.

Software rot is either a slow deterioration of software quality over time or its diminishing responsiveness that will eventually lead to software becoming faulty, unusable, or in need of upgrade. This is not a physical phenomenon; the software does not actually decay, but rather suffers from a lack of being responsive and updated with respect to the changing environment in which it resides.

Object-oriented analysis and design (OOAD) is a technical approach for analyzing and designing an application, system, or business by applying object-oriented programming, as well as using visual modeling throughout the software development process to guide stakeholder communication and product quality.

William F. "Bill" Opdyke is an American computer scientist and enterprise architect at JPMorgan Chase, known for his early work on code refactoring.

In software development, or any other IT field technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

Domain-driven design (DDD) is a major software design approach, focusing on modeling software to match a domain according to input from that domain's experts.

Rule of three is a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code do not require refactoring, but when similar code is used three times, it should be extracted into a new procedure. The rule was popularised by Martin Fowler in Refactoring and attributed to Don Roberts.

In computer science, information hiding is the principle of segregation of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed. The protection involves providing a stable interface which protects the remainder of the program from the implementation. Written in another way, information hiding is the ability to prevent certain aspects of a class or software component from being accessible to its clients, using either programming language features or an explicit exporting policy.

In software engineering and programming language theory, the abstraction principle is a basic dictum that aims to reduce duplication of information in a program whenever practical by making use of abstractions provided by the programming language or software libraries. The principle is sometimes stated as a recommendation to the programmer, but sometimes stated as a requirement of the programming language, assuming it is self-understood why abstractions are desirable to use. The origins of the principle are uncertain; it has been reinvented a number of times, sometimes under a different name, with slight variations.

<span class="mw-page-title-main">Object-oriented programming</span> Programming paradigm based on the concept of objects

Object-oriented programming (OOP) is a programming paradigm based on the concept of objects, which can contain data and code: data in the form of fields, and code in the form of procedures. In OOP, computer programs are designed by making them out of objects that interact with one another.

In object-oriented programming, "data clump" is a name given to any group of variables which are passed around together throughout various parts of the program. A data clump, like other code smells, can indicate deeper problems with the program design or implementation. The group of variables that typically make up a data clump are often closely related or interdependent and are often used together in a group as a result. A data clump is also known as a specific kind of class-level code smell that may be a symptom of poorly written source code.

References

  1. 1 2 3 4 5 6 7 8 9 10 11 12 Girish Suryanarayana, Ganesh SG, Tushar Sharma (2014). "Refactoring for software design smells: Managing technical debt". Morgan Kaufmann. ISBN   978-0128013977
  2. 1 2 3 4 5 Fowler, Martin (1999). Refactoring. Improving the Design of Existing Code. Addison-Wesley. ISBN   0-201-48567-2.
  3. 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.
  4. R. C. Martin. Agile Software Development, Principles, Patterns, and Practices. Addison-Wesley, 2003.
  5. Trifu A. "Automated strategy based restructuring of object oriented code". In Proceedings of the 7th German workshop on software-reengineering (WSR); 2005.
  6. Stal M. "Software architecture refactoring". Tutorial in The international conference on object oriented programming, systems, languages and applications (OOPSLA); 2007.
  7. Page-Jones M. "The practical guide to structured systems design". 2nd ed. Prentice Hall; 1988.
  8. Sefika M, Sane A, Campbell RH. "Monitoring compliance of a software system with its high-level design models". In Proceedings of the 18th international conference on software engineering, ICSE ‘96, Washington, DC; 1996. p. 387–96.
  9. Budd T. "An introduction to object-oriented programming". 3rd ed. Addison Wesley; 2001.
  10. Page-Jones M. "Fundamentals of object-oriented design in UML". Addison-Wesley Professional; 1999.