What is an anti-pattern?

Anti-patterns are certain patterns in software development that are considered bad programming practices.

As opposed to design patterns which are common approaches to common problems which have been formalized and are generally considered a good development practice, anti-patterns are the opposite and are undesirable.

For example, in object-oriented programming, the idea is to separate the software into small pieces called objects. An anti-pattern in object-oriented programming is a God object which performs a lot of functions which would be better separated into different objects.

For example:

class GodObject {
    function PerformInitialization() {}
    function ReadFromFile() {}
    function WriteToFile() {}
    function DisplayToScreen() {}
    function PerformCalculation() {}
    function ValidateInput() {}
    // and so on... //
}

The example above has an object that does everything. In object-oriented programming, it would be preferable to have well-defined responsibilities for different objects to keep the code less coupled and ultimately more maintainable:

class FileInputOutput {
    function ReadFromFile() {}
    function WriteToFile() {}
}

class UserInputOutput {
    function DisplayToScreen() {}
    function ValidateInput() {}
}

class Logic {
    function PerformInitialization() {}
    function PerformCalculation() {}
}

The bottom line is there are good ways to develop software with commonly used patterns (design patterns), but there are also ways software is developed and implemented which can lead to problems. Patterns that are considered bad software development practices are anti-patterns.

A pattern is an idea of how to solve a problem of some class. An anti-pattern is an idea of how not to solve it because implementing that idea would result in bad design.

An example: a "pattern" would be to use a function for code reuse, an "anti-pattern" would be to use copy-paste for the same. Both solve the same problem, but using a function usually leads to more readable and maintainable code than copy-paste.

An anti-pattern is a way of not solving a problem. But there is more to it: it is also a way that can frequently be seen in attempts to solve the problem.

If you really wish to study AntiPatterns, get the book AntiPatterns (ISBN-13: 978-0471197133).

In it, they define "An AntiPattern is a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences."

So, if it's a bad programming practice but not a common one— very limited in frequency of occurrence, it does not meet the "Pattern" part of the AntiPattern definition.

Just like with a design pattern, an anti-pattern is also a template and a repeatable way of solving a certain problem, but in a non-optimal and ineffective way.

Interestingly a given way of solving a problem can be both a pattern and an anti-pattern. Singleton is the prime example of this. It will appear in both sets of literature.

A common way to make a mess. Like the god/kitchensink class (does everything), for example.

Anti-patterns are common ways people tend to program the wrong way, or at least the not so good way.

It is sometimes used when you misuse design patterns in an illegal way, or you don't know the actual usage of it. For example, having builder pattern for simple classes, or obsessively defining one singleton instance for each Active class you use in your code.

Also it might be beyond design patterns. For example, defining local variables in Java as final, or using try / catch for NullPointerException when you could simply check input against being null, or nulling objects after they are used (like what you do in some other languages) that you don't notice about garbage collection mechanism, or calling system.gc() to make memory empty, and many other misunderstandings, which are quite likely to be considered as Cargo-Cult phenomena.

In Microservices based area:

Everything is micro except for data is an anti-pattern. It means that if every thing is decomposed reasonable and fully based on DevOps and CI/CD. Maybe some distributed design patterns are in place and even fully replicated, but there is one giant data store behind all of the services, so it is still a monolithic data structure.

Other example of Microservices anti-pattern

Because patterns are discovered not being created ^{Allen Holub} and this discovery happens through repetition; if we have discovered a pattern that solves a particular problem but not in the right way according to domain experts knowledge and experience - we tend to call it anti-pattern

pattern: the right way of solving a common, reoccurring problem.
anit-pattern: not the right way of solving a common, reoccurring problem.
both of these based on latest and up to date knowledge

And ... Yesterday's pest practice is tomorrow's anti-pattern ^{Neal Ford, Engineering-Practices-for-Continuous-Delivery}

DevOps worlds examples

It used to be a best practice (Architecting Shared Resources)

But in cloud world it introduces coupling when we manage our resources in cloud.

So nowadays we tend to architect our design based on decoupling or uncouple it ^{Uncoupling • Michael Nygard • GOTO 2018}

Thus for a specific domain e.g. DevOps:

Past:
Shared Resources == pattern == good thing
Present:
Shared Resources == anti-pattern == bad thing
Decoupling == pattern == good thing

in a word

Prefer pattern over anti-pattern

Image source: Neal Ford, Engineering-Practices-for-Continuous-Delivery