Anti-Patterns

Anti-pattern: An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. The term, coined in 1995 by computer programmer Andrew Koenig, was inspired by the book Design Patterns, which highlights a number of design patterns in software development that its authors considered to be highly reliable and effective.

According to the authors of Design Patterns, there are two key elements to an anti-pattern that distinguish it from a bad habit, bad practice, or bad idea:

1. The anti-pattern is a commonly-used process, structure or pattern of action that, despite initially appearing to be an appropriate and effective response to a problem, has more bad consequences than good ones
2. Another solution to the problem the anti-pattern is attempting to address exists, which is documented, repeatable and proven to be effective where the anti-pattern is not

• Abstraction inversion: Not exposing implemented functionality required by callers of a function/method/constructor, so that the calling code awkwardly re-implements the same functionality in terms of those calls
• Ambiguous viewpoint: Presenting a model (usually Object-oriented analysis and design (OOAD)) without specifying its viewpoint
• Big ball of mud: A system with no recognizable structure
• Race hazard (or race condition): Failing to see the consequences of events that can sometimes interfere with each other.
• Stovepipe system: A barely maintainable assemblage of ill-related components

• Call super: Requiring subclasses to call a superclass's overridden method
• 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
• Singleton Pattern: This design pattern brings coupling and is considered a bad solution
• Yo-yo problem: A structure (e.g., of inheritance) that is hard to understand due to excessive fragmentation

• Copy and paste programming: Copying (and modifying) existing code rather than creating generic solutions
• Golden hammer: Assuming that a favorite solution is universally applicable (See: Silver bullet)
• Invented here: The tendency towards dismissing any innovation or less than trivial solution originating from inside the organization, usually because of lack of confidence in the staff
• Not invented here (NIH) syndrome: The tendency towards reinventing the wheel (failing to adopt an existing, adequate solution)
• Programming by permutation (or "programming by accident", or "programming by coincidence"): Trying to approach a solution by successively modifying the code to see if it works
• Reinventing the square wheel: Failing to adopt an existing solution and instead adopting a custom solution that performs much worse than the existing one
• Silver bullet: Assuming that a favorite technical solution can solve a larger process or problem
• Tester-driven development: Software projects in which new requirements are specified in bug reports

Also when formulating textual definitions, those that are circular should be avoided. As a basis for ontological definitions, this would immediately lead to incorrect modeling. The Healthcare Interoperability Resource Specification (FHIR) defines: "container = def. a container of other entities" ArSm2015, page xx.