Object-oriented design anti-patterns
From CSSEMediaWiki
(Difference between revisions)
m |
m (Reverted edits by Ebybymic (Talk); changed back to last version by Matthew Harward) |
||
| (11 intermediate revisions by 2 users not shown) | |||
| Line 4: | Line 4: | ||
The following are common object-oriented design anti-patterns: | The following are common object-oriented design anti-patterns: | ||
| − | |||
| − | |||
*[[Anemic Domain Model]] - This anti-pattern occurs when data and behaviour is separated in the domain model. | *[[Anemic Domain Model]] - This anti-pattern occurs when data and behaviour is separated in the domain model. | ||
*[[BaseBean]] - This anti-pattern occurs when inheritance for implementation is used; that is a class inherits from another class not because it makes sense semantically but because it wants to use methods defined in the superclass. | *[[BaseBean]] - This anti-pattern occurs when inheritance for implementation is used; that is a class inherits from another class not because it makes sense semantically but because it wants to use methods defined in the superclass. | ||
| − | *[[Boat anchor]] - A piece of software or hardware in the system that serves no useful purpose. | + | *[[Boat anchor]] - A piece of software or hardware in the system that serves no useful purpose. [[William Brown 1998|WB]] |
*[[Call super]] - This anti-pattern occurs when a superclass requires derived classes to call an overridden method. | *[[Call super]] - This anti-pattern occurs when a superclass requires derived classes to call an overridden method. | ||
*[[Circle-ellipse problem]] - This anti-pattern occurs when inheritance is not used correctly and the [[Liskov substitution principle]] is violated. | *[[Circle-ellipse problem]] - This anti-pattern occurs when inheritance is not used correctly and the [[Liskov substitution principle]] is violated. | ||
*[[Circular dependency]] - This anti-pattern occurs when there are two or more modules that depend directly or indirectly on each other. | *[[Circular dependency]] - This anti-pattern occurs when there are two or more modules that depend directly or indirectly on each other. | ||
*[[Constant interface]] - This anti-pattern occurs when an interface is used to declare constants but does not contain any methods. | *[[Constant interface]] - This anti-pattern occurs when an interface is used to declare constants but does not contain any methods. | ||
| − | *[[Cut and paste programming]] - Code reused by copying source from other locations. Increasing the likelihood of errors and decreases maintainability. | + | *[[Cut and paste programming]] - Code reused by copying source from other locations. Increasing the likelihood of errors and decreases maintainability. [[William Brown 1998|WB]] |
| − | *[[Functional decomposition]] - Classes that resemble the structure of programs creating using functional languages. | + | *[[Functional decomposition]] - Classes that resemble the structure of programs creating using functional languages. [[William Brown 1998|WB]] |
*[[God object]] - This anti-pattern occurs when an object / class does or knows too much. | *[[God object]] - This anti-pattern occurs when an object / class does or knows too much. | ||
| + | *[[Jumble]] - This anti-pattern describes a situation where "horizontal and vertical design elements are intermixed". This means that domain specific concepts are mixed with hierarchical concepts. [[William Brown 1998|WB]] | ||
*[[Object cesspool]] - This anti-pattern occurs when an object pool is used incorrectly in that the state of objects is not reset when they are returned to the pool. | *[[Object cesspool]] - This anti-pattern occurs when an object pool is used incorrectly in that the state of objects is not reset when they are returned to the pool. | ||
*[[Object orgy]] - This anti-pattern occurs when objects access each other internals directly rather than going through methods. | *[[Object orgy]] - This anti-pattern occurs when objects access each other internals directly rather than going through methods. | ||
*[[Poltergeists]] - This anti-pattern occurs when temporary objects are used to initialize or call methods on more permanent objects. | *[[Poltergeists]] - This anti-pattern occurs when temporary objects are used to initialize or call methods on more permanent objects. | ||
| + | *[[Reinvent the wheel]] - This occurs when developers reinvent material that already exists. This is the "if you write quicksort ever again you're fired" antipattern. [[William Brown 1998|WB]] | ||
*[[Sequential coupling]] - This anti-pattern occurs when a class requires clients to call methods in a particular order. | *[[Sequential coupling]] - This anti-pattern occurs when a class requires clients to call methods in a particular order. | ||
| − | *[[Spaghetti code]] - An adhoc structure that is difficult to extend and maintain. | + | *[[Spaghetti code]] - An adhoc structure that is difficult to extend and maintain. [[William Brown 1998|WB]] |
| − | *[[God object|The Blob]] - Equivalent to [[God object]], a very large class with a functional structure. | + | *[[Stovepipe system]] - The integration of subsystems in an adhoc manner. [[William Brown 1998|WB]] |
| + | *[[Swiss army knife]] - An excessively complicating interface in which the designer attempts to provide every conceivable functionality. [[William Brown 1998|WB]] | ||
| + | *[[God object|The Blob]] - Equivalent to [[God object]], a very large class with a functional structure. [[William Brown 1998|WB]] | ||
| + | *[[Vendor lock-in]] - Occurs in systems that are highly dependent on propitiatory architectures. [[William Brown 1998|WB]] | ||
*[[Yo-yo problem]] - This problem occurs with deep inheritance hierarchies, where a programmer has to keep looking up and down the hierarchy to understand the flow of control of the program. | *[[Yo-yo problem]] - This problem occurs with deep inheritance hierarchies, where a programmer has to keep looking up and down the hierarchy to understand the flow of control of the program. | ||
| − | |||
| − | |||
| − | |||
| − | |||
==See also== | ==See also== | ||
* [[Antipatterns]] | * [[Antipatterns]] | ||
* [[Design patterns]] | * [[Design patterns]] | ||
| + | * [[William Brown 1998]] - A selection of the antipatterns from this text are listed above. | ||
| + | * [[Management antipatterns]] | ||
{{Design Anti-patterns}} | {{Design Anti-patterns}} | ||
[[Category: Anti-Patterns]] | [[Category: Anti-Patterns]] | ||
Latest revision as of 03:10, 25 November 2010
Object-oriented design anti-patterns describe bad design solutions to common problems. As such, they are essentially the opposite of conventional design patterns.
Many of these anti-patterns are closely related to common design maxims.
The following are common object-oriented design anti-patterns:
- Anemic Domain Model - This anti-pattern occurs when data and behaviour is separated in the domain model.
- BaseBean - This anti-pattern occurs when inheritance for implementation is used; that is a class inherits from another class not because it makes sense semantically but because it wants to use methods defined in the superclass.
- Boat anchor - A piece of software or hardware in the system that serves no useful purpose. WB
- Call super - This anti-pattern occurs when a superclass requires derived classes to call an overridden method.
- Circle-ellipse problem - This anti-pattern occurs when inheritance is not used correctly and the Liskov substitution principle is violated.
- Circular dependency - This anti-pattern occurs when there are two or more modules that depend directly or indirectly on each other.
- Constant interface - This anti-pattern occurs when an interface is used to declare constants but does not contain any methods.
- Cut and paste programming - Code reused by copying source from other locations. Increasing the likelihood of errors and decreases maintainability. WB
- Functional decomposition - Classes that resemble the structure of programs creating using functional languages. WB
- God object - This anti-pattern occurs when an object / class does or knows too much.
- Jumble - This anti-pattern describes a situation where "horizontal and vertical design elements are intermixed". This means that domain specific concepts are mixed with hierarchical concepts. WB
- Object cesspool - This anti-pattern occurs when an object pool is used incorrectly in that the state of objects is not reset when they are returned to the pool.
- Object orgy - This anti-pattern occurs when objects access each other internals directly rather than going through methods.
- Poltergeists - This anti-pattern occurs when temporary objects are used to initialize or call methods on more permanent objects.
- Reinvent the wheel - This occurs when developers reinvent material that already exists. This is the "if you write quicksort ever again you're fired" antipattern. WB
- Sequential coupling - This anti-pattern occurs when a class requires clients to call methods in a particular order.
- Spaghetti code - An adhoc structure that is difficult to extend and maintain. WB
- Stovepipe system - The integration of subsystems in an adhoc manner. WB
- Swiss army knife - An excessively complicating interface in which the designer attempts to provide every conceivable functionality. WB
- The Blob - Equivalent to God object, a very large class with a functional structure. WB
- Vendor lock-in - Occurs in systems that are highly dependent on propitiatory architectures. WB
- Yo-yo problem - This problem occurs with deep inheritance hierarchies, where a programmer has to keep looking up and down the hierarchy to understand the flow of control of the program.
See also
- Antipatterns
- Design patterns
- William Brown 1998 - A selection of the antipatterns from this text are listed above.
- Management antipatterns
| Design anti-patterns | |
|---|---|
|
Anemic Domain Model | BaseBean | Call super | Circle-ellipse problem | Circular dependency | |
