Anti-pattern
Encyclopedia : A : AN : ANT : Anti-pattern
Anti-patterns, also referred to as pitfalls, are classes of commonly-reinvented bad solutions to problems. They are studied, as a category, in order that they may be avoided in the future, and that instances of them may be recognized when investigating non-working systems.
The term originates in computer science, apparently inspired by the Gang of Four's Design Patterns book, which laid out examples of good programming practice. The authors termed these good methods "design patterns", by analogy with the term as used in architecture. "Anti-patterns", as described in the book by Brown, Malveau, McCormick and Mowbray, are a natural counterpart, though not mentioned in the original Design Patterns book. Part of good programming practice is the avoidance of anti-patterns.
The concept is readily applied to engineering in general, and also applies outside engineering, in any human endeavour. Although the term is not commonly used outside engineering, the concept is quite universal.
Contents
Some recognised
- For a more comprehensive, alphabetical list, see .
- Smoke and mirrors: Demonstrating how unimplemented functions will appear
- Software bloat: Allowing successive versions of a system to demand ever more resources
- Abstraction inversion: Not exposing functionality required by users, so that they re-implement it using higher level functions
- Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
- Big ball of mud: A system with no recognisable structure
- Blob: see God object
- Gas factory: An unnecessarily complex design
- Input kludge: Failing to specify and implement handling of possibly invalid input
- Interface bloat: Making an interface so powerful that it is too hard to implement
Magic pushbutton: Implementing the results of user actions in terms of an inappropriate (insufficiently abstract) interface Re-Coupling: Introducing unnecessary object dependency Stovepipe system: A barely maintainable assemblage of ill-related components Race hazard: Failing to see the consequence of different orders of events
- BaseBean: Inheriting functionality from a utility class rather than delegating to it
- Empty subclass failure: Creating a (Perl) class that fails the "[Empty Subclass Test]" by behaving differently from a class derived from it without modifications
- God object: Concentrating too many functions in a single part of the design (class)
- Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
- Poltergeists: Objects whose sole purpose is to pass information to another object
- Yo-yo problem: A structure (e.g. of inheritance) that is hard to understand due to excessive fragmentation
- Anemic Domain Model: The use of domain model without any business logic which is not OO because each object should have both attributes and behaviors.
- Sequential Coupling: When a class requires you call methods in a particular order and will break if you don't. Methods whose name starts with Init, Begin, Start, etc. may be a tell tale symptom of this anti-pattern.
- Accidental complexity: Introducing unnecessary complexity into a solution
- Action at a distance: Unexpected interaction between widely separated parts of a system
- Accumulate and fire: Setting parameters for subroutines in a collection of global variables
- Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
- Boat anchor: Retaining a part of a system that no longer has any use
- Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of proper messaging
- Caching failure: Forgetting to reset an error flag when an error has been corrected
- Checking type instead of interface: Checking that an object has a specific type when only a certain contract is required
- Code momentum: Over-constraining part of a system by repeatedly assuming things about it in other parts
- Coding by exception: Adding new code to handle each special case as it is recognised
- Double-checked locking: Checking, before locking, if this is necessary in a way which may fail with e.g. modern hardware or compilers.
- Hard code: Embedding assumptions about the environment of a system at many points in its implementation
- Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences
- Magic numbers: Including unexplained numbers in algorithms
- Procedural code (when another paradigm is more appropriate)
- Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures
- Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
- De-factoring: The process of removing functionality and replacing it with documentation
- Golden hammer: Assuming that a favorite solution is universally applicable
- Silver bullet: Assuming that a favorite or technical solution can solve a larger or process problem.
- Improbability factor: Assuming that it is improbable that a known error becomes effective
- Premature optimization: Optimization on the basis of insufficient information
- Reinventing the wheel: Failing to adopt an existing solution
- Reinventing the square wheel: Creating a poor solution when a good one exists
- Dependency hell: Problems with versions of required products, specifically on UNIX/Linux
- DLL hell: Problems with versions, availability and multiplication of DLLs, specifically on Microsoft Windows
Some organisational anti-patterns
- Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
- Cash cow: A profitable legacy product that often leads to complacency about new products
- Continuous obsolescence: Devoting disproportionate effort to porting a system to new environments
- Cost migration: Transfer of project expenses to a vulnerable department or business partner
- Creeping featurism: Adding new features to the detriment of the quality of a system
- Design by committee: The result of having many contributors to a design, but no unifying vision
- Escalation of commitment: Failing to revoke a decision when it proves wrong
- I told you so: When the ignored warning of an expert proves justified
- Management by numbers: Paying excessive attention to quantitative management criteria, when these are inessential or cost too much to acquire
- Management by perkele: Army-style management with no tolerance for dissent
- Mushroom management: Keeping employees uninformed and abused
- Scope creep: Allowing the scope of a project to grow without proper control
- Vendor lock-in: Making a system excessively dependent on an externally supplied component
- Warm body: A person whose contribution to a project is in doubt, especially if taken on in panic
See also
References
- Perl Design Patterns – A free online book
External links
- Smoke and mirrors: Demonstrating how unimplemented functions will appear
- Software bloat: Allowing successive versions of a system to demand ever more resources
- Abstraction inversion: Not exposing functionality required by users, so that they re-implement it using higher level functions
- Ambiguous viewpoint: Presenting a model (usually OOAD) without specifying its viewpoint
- Big ball of mud: A system with no recognisable structure
- Blob: see God object
- Gas factory: An unnecessarily complex design
- Input kludge: Failing to specify and implement handling of possibly invalid input
- Interface bloat: Making an interface so powerful that it is too hard to implement
Magic pushbutton: Implementing the results of user actions in terms of an inappropriate (insufficiently abstract) interface Re-Coupling: Introducing unnecessary object dependency Stovepipe system: A barely maintainable assemblage of ill-related components Race hazard: Failing to see the consequence of different orders of events
- BaseBean: Inheriting functionality from a utility class rather than delegating to it
- Empty subclass failure: Creating a (Perl) class that fails the "[Empty Subclass Test]" by behaving differently from a class derived from it without modifications
- God object: Concentrating too many functions in a single part of the design (class)
- Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
- Poltergeists: Objects whose sole purpose is to pass information to another object
- Yo-yo problem: A structure (e.g. of inheritance) that is hard to understand due to excessive fragmentation
- Anemic Domain Model: The use of domain model without any business logic which is not OO because each object should have both attributes and behaviors.
- Sequential Coupling: When a class requires you call methods in a particular order and will break if you don't. Methods whose name starts with Init, Begin, Start, etc. may be a tell tale symptom of this anti-pattern.
- Accidental complexity: Introducing unnecessary complexity into a solution
- Action at a distance: Unexpected interaction between widely separated parts of a system
- Accumulate and fire: Setting parameters for subroutines in a collection of global variables
- Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
- Boat anchor: Retaining a part of a system that no longer has any use
- Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of proper messaging
- Caching failure: Forgetting to reset an error flag when an error has been corrected
- Checking type instead of interface: Checking that an object has a specific type when only a certain contract is required
- Code momentum: Over-constraining part of a system by repeatedly assuming things about it in other parts
- Coding by exception: Adding new code to handle each special case as it is recognised
- Double-checked locking: Checking, before locking, if this is necessary in a way which may fail with e.g. modern hardware or compilers.
- Hard code: Embedding assumptions about the environment of a system at many points in its implementation
- Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences
- Magic numbers: Including unexplained numbers in algorithms
- Procedural code (when another paradigm is more appropriate)
- Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures
- Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
- De-factoring: The process of removing functionality and replacing it with documentation
- Golden hammer: Assuming that a favorite solution is universally applicable
- Silver bullet: Assuming that a favorite or technical solution can solve a larger or process problem.
- Improbability factor: Assuming that it is improbable that a known error becomes effective
- Premature optimization: Optimization on the basis of insufficient information
- Reinventing the wheel: Failing to adopt an existing solution
- Reinventing the square wheel: Creating a poor solution when a good one exists
- Dependency hell: Problems with versions of required products, specifically on UNIX/Linux
- DLL hell: Problems with versions, availability and multiplication of DLLs, specifically on Microsoft Windows
Some organisational anti-patterns
- Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
- Cash cow: A profitable legacy product that often leads to complacency about new products
- Continuous obsolescence: Devoting disproportionate effort to porting a system to new environments
- Cost migration: Transfer of project expenses to a vulnerable department or business partner
- Creeping featurism: Adding new features to the detriment of the quality of a system
- Design by committee: The result of having many contributors to a design, but no unifying vision
- Escalation of commitment: Failing to revoke a decision when it proves wrong
- I told you so: When the ignored warning of an expert proves justified
- Management by numbers: Paying excessive attention to quantitative management criteria, when these are inessential or cost too much to acquire
- Management by perkele: Army-style management with no tolerance for dissent
- Mushroom management: Keeping employees uninformed and abused
- Scope creep: Allowing the scope of a project to grow without proper control
- Vendor lock-in: Making a system excessively dependent on an externally supplied component
- Warm body: A person whose contribution to a project is in doubt, especially if taken on in panic
See also
References
- Perl Design Patterns – A free online book
External links
- BaseBean: Inheriting functionality from a utility class rather than delegating to it
- Empty subclass failure: Creating a (Perl) class that fails the "[Empty Subclass Test]" by behaving differently from a class derived from it without modifications
- God object: Concentrating too many functions in a single part of the design (class)
- Object cesspool: Reusing objects whose state does not conform to the (possibly implicit) contract for re-use
- Poltergeists: Objects whose sole purpose is to pass information to another object
- Yo-yo problem: A structure (e.g. of inheritance) that is hard to understand due to excessive fragmentation
- Anemic Domain Model: The use of domain model without any business logic which is not OO because each object should have both attributes and behaviors.
- Sequential Coupling: When a class requires you call methods in a particular order and will break if you don't. Methods whose name starts with Init, Begin, Start, etc. may be a tell tale symptom of this anti-pattern.
- Accidental complexity: Introducing unnecessary complexity into a solution
- Action at a distance: Unexpected interaction between widely separated parts of a system
- Accumulate and fire: Setting parameters for subroutines in a collection of global variables
- Blind faith: Lack of checking of (a) the correctness of a bug fix or (b) the result of a subroutine
- Boat anchor: Retaining a part of a system that no longer has any use
- Busy spin: Consuming CPU while waiting for something to happen, usually by repeated checking instead of proper messaging
- Caching failure: Forgetting to reset an error flag when an error has been corrected
- Checking type instead of interface: Checking that an object has a specific type when only a certain contract is required
- Code momentum: Over-constraining part of a system by repeatedly assuming things about it in other parts
- Coding by exception: Adding new code to handle each special case as it is recognised
- Double-checked locking: Checking, before locking, if this is necessary in a way which may fail with e.g. modern hardware or compilers.
- Hard code: Embedding assumptions about the environment of a system at many points in its implementation
- Lava flow: Retaining undesirable (redundant or low-quality) code because removing it is too expensive or has unpredictable consequences
- Magic numbers: Including unexplained numbers in algorithms
- Procedural code (when another paradigm is more appropriate)
- Spaghetti code: Systems whose structure is barely comprehensible, especially because of misuse of code structures
- Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
- De-factoring: The process of removing functionality and replacing it with documentation
- Golden hammer: Assuming that a favorite solution is universally applicable
- Silver bullet: Assuming that a favorite or technical solution can solve a larger or process problem.
- Improbability factor: Assuming that it is improbable that a known error becomes effective
- Premature optimization: Optimization on the basis of insufficient information
- Reinventing the wheel: Failing to adopt an existing solution
- Reinventing the square wheel: Creating a poor solution when a good one exists
- Dependency hell: Problems with versions of required products, specifically on UNIX/Linux
- DLL hell: Problems with versions, availability and multiplication of DLLs, specifically on Microsoft Windows
Some organisational anti-patterns
- Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
- Cash cow: A profitable legacy product that often leads to complacency about new products
- Continuous obsolescence: Devoting disproportionate effort to porting a system to new environments
- Cost migration: Transfer of project expenses to a vulnerable department or business partner
- Creeping featurism: Adding new features to the detriment of the quality of a system
- Design by committee: The result of having many contributors to a design, but no unifying vision
- Escalation of commitment: Failing to revoke a decision when it proves wrong
- I told you so: When the ignored warning of an expert proves justified
- Management by numbers: Paying excessive attention to quantitative management criteria, when these are inessential or cost too much to acquire
- Management by perkele: Army-style management with no tolerance for dissent
- Mushroom management: Keeping employees uninformed and abused
- Scope creep: Allowing the scope of a project to grow without proper control
- Vendor lock-in: Making a system excessively dependent on an externally supplied component
- Warm body: A person whose contribution to a project is in doubt, especially if taken on in panic
See also
References
- Perl Design Patterns – A free online book
External links
- Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
- De-factoring: The process of removing functionality and replacing it with documentation
- Golden hammer: Assuming that a favorite solution is universally applicable
- Silver bullet: Assuming that a favorite or technical solution can solve a larger or process problem.
- Improbability factor: Assuming that it is improbable that a known error becomes effective
- Premature optimization: Optimization on the basis of insufficient information
- Reinventing the wheel: Failing to adopt an existing solution
- Reinventing the square wheel: Creating a poor solution when a good one exists
- Dependency hell: Problems with versions of required products, specifically on UNIX/Linux
- DLL hell: Problems with versions, availability and multiplication of DLLs, specifically on Microsoft Windows
Some organisational anti-patterns
- Analysis paralysis: Devoting disproportionate effort to the analysis phase of a project
- Cash cow: A profitable legacy product that often leads to complacency about new products
- Continuous obsolescence: Devoting disproportionate effort to porting a system to new environments
- Cost migration: Transfer of project expenses to a vulnerable department or business partner
- Creeping featurism: Adding new features to the detriment of the quality of a system
- Design by committee: The result of having many contributors to a design, but no unifying vision
- Escalation of commitment: Failing to revoke a decision when it proves wrong
- I told you so: When the ignored warning of an expert proves justified
- Management by numbers: Paying excessive attention to quantitative management criteria, when these are inessential or cost too much to acquire
- Management by perkele: Army-style management with no tolerance for dissent
- Mushroom management: Keeping employees uninformed and abused
- Scope creep: Allowing the scope of a project to grow without proper control
- Vendor lock-in: Making a system excessively dependent on an externally supplied component
- Warm body: A person whose contribution to a project is in doubt, especially if taken on in panic
See also
References
- Perl Design Patterns – A free online book
External links
From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.