Object-oriented design anti-patterns

From CSSEMediaWiki
(Difference between revisions)
Jump to: navigation, search
m (Development & Management Antipatterns)
m (Development & Management Antipatterns)
Line 28: Line 28:
 
*[[Lava Flow]] - Dead and forgotten code that hardens and becomes unchanged as the system develops. Requires a change in development strategy.
 
*[[Lava Flow]] - Dead and forgotten code that hardens and becomes unchanged as the system develops. Requires a change in development strategy.
 
*[[Mushroom management]] - This occurs when developers are separated from the end users.
 
*[[Mushroom management]] - This occurs when developers are separated from the end users.
 +
*[[Golden hammer]] - When a single technique is applied "obsessively" to software problems.
  
 
==See also==
 
==See also==

Revision as of 10:27, 23 September 2009

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:

Architecture 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.
  • 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.
  • Functional decomposition - Classes that resemble the structure of programs creating using functional languages.
  • God object - This anti-pattern occurs when an object / class does or knows too much.
  • 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.
  • 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.
  • The Blob - Equivalent to God object, a very large class with a functional structure.
  • 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.

Development & Management Antipatterns

  • Lava Flow - Dead and forgotten code that hardens and becomes unchanged as the system develops. Requires a change in development strategy.
  • Mushroom management - This occurs when developers are separated from the end users.
  • Golden hammer - When a single technique is applied "obsessively" to software problems.

See also


Personal tools