What are antipatterns?

Definition “Anti-pattern”
What are antipatterns?

By Gedeon Rauch

providers on the subject

With the help of design patterns, certain rules can be derived in the design, which act as guidelines for better design. It is also about avoiding systemic errors, including the so-called anti-patterns.

Anti-patterns often manifest in the form of technical debt and “bad” code, an example of which is spaghetti code.

(Image: Markus Spiske (markuspiske) / Unsplash)

Frequently occurring problems can often be solved with common strategies, in software development we talk about design patterns. This works, even though these solutions themselves are ineffective and can have unwanted side effects.

In such cases, one speaks of the so-called anti-pattern: the solution to a problem is itself a problem, but is still used. This is the case because the solution to the problem initially looks like a suitable solution and is actually capable of solving the problem. The unwanted consequences are an aftereffect that is hardly thought of in advance.

But to truly count as an anti-pattern in design pattern theory, another condition must be met. There is a better, more efficient solution that can be used repeatedly and reliably, but is not being used.

The term anti-pattern originally comes from development and goes back to Andrew Koenig and the book “Design Patterns” (1995). Meanwhile, the term has also become common in software engineering or project management.

Understand the Anti-Pattern better with the example

The design patterns are used by developers as general solutions to common problems and are considered a positive example of solving a problem. A pattern is repeatable and effective.

This does not apply to anti-patterns, the lack of efficiency is often noticeable in the form of technical debt and thus leads to higher costs, lengthy refactoring or an overall unattractive code. The best way to understand developing anti-patterns is to look at a few examples.

Spaghetti code

A program that grows and constantly gets new functions also grows relatively quickly in the code. It’s a tempting solution to just keep writing code and copy it at will without paying attention to adequate modularization.

The spaghetti code sort of solves the problem by allowing new functionality to be implemented, and up until a point it will do just fine. However, this creates a fragile and confusing structure that is difficult to navigate, especially for external help.

Boat Anchor

Not all functions need to be included immediately in a program, often these need to be added only in the future. To insert the functions later, a few lines are added when the code is initially written, which may be needed later. These serve as boat anchors.

However, whether the code is actually inserted in the future, or if puzzling lines are simply up to the point of madness, looking at the code, the code is unnecessarily inflated by the boat anchor.

Dead code

Dead Code is similar to Boat Anchor, except that it is not planned for the future, but is from an earlier version of the program. Dead code used to have a purpose, but features have been removed or never completed, and now the code is still bloated, and non-functional lines of code bloat the program.

God’s class

The God class is a common problem and also an anti-pattern. While the classes should remain limited to single responsibilities, the God class takes on as much as it can.

As a rule, shortcuts were taken when coding and instead of creating new classes, several tasks were transferred to an already existing class. Again, this initially solves a problem, but is a very inefficient solution and will ultimately yield a maintainable class.

To recognize and avoid anti-patterns

Not every ineffective problem solving is an anti-pattern. Such a “problem solution” should occur at least three times in order to actually derive a pattern from it.

Like patterns, anti-patterns have a positive side effect because the best way to learn is from patterns. If something always causes problems, then the design can predict with certainty that it will cause problems again – and it can be avoided.

Incidentally, Andrew Koenig already had a sharp and catchy formulation for the definition of anti-patterns in “Design Patterns”: “An anti-pattern is comparable to a pattern, except that instead of a solution it offers something that superficially looks like a solution, but none is.”

Anti-patterns are also incredibly useful because of an often overlooked part of their definition: there is a more efficient and repeatable solution. Implementing a suboptimal solution with no alternatives is not an anti-pattern. Creating technical debt (whether due to lack of time, lack of skills or to carry on a legacy) is only when there are alternative methods that remain unused.


Leave a Comment