Object-oriented design anti-patterns

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Reverted edits by Ebybymic (Talk); changed back to last version by Matthew Harward)
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
Object-oriented design anti-patterns describe bad design solutions to common problems. As such, they are essentially the opposite of conventional design patterns.
 
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:
 
The following are common object-oriented design anti-patterns:
  
−
*[[Anemic Domain Model]] - This anti-pattern occurs when data and behavior 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. [[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.
−
*[[Lava Flow]] - Dead and forgotten code that hardens and becomes unchanged as the system develops. Requires a change in development strategy.
+
*[[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.
−
 
−
Many of these anti-patterns are closely related to common design maxims.
 
  
 
==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


Retrieved from "https://oowisdom.csse.canterbury.ac.nz/index.php?title=Object-oriented_design_anti-patterns&oldid=9295"
Personal tools