Patterns have often, more recently, gotten a misunderstood reputation. The Gang Of Four book was written in 1994, but if you talked to many developers today they’d look at you like you were clueless if you said observational pattern. The most popular form, in software engineering, is best practice/design patterns. Those give vague high level, experienced, recommendations about how you should structure code to solve a particular problem. Anti-patterns is something a bit more vague. It’s easy to recognize the good practices, but it’s often hard to talk about the bad practices. Bad practices are rarely duplicated. They do cluster arround some similarities, but it’s very rare to reproduce them in the same manner. It’s even harder to do this, since bad coding structures often depend on the context in which the code was written.
What are some examples of Antipatterns?
Some antipatterns could include, a lack of error checking, they could be re-creating a database from scratch, using message queues as a networking protocol, exploiting internal non-public operations of a framework, using a database as a queue, or it could even be more granular in overloading a single class with way too many methods.
Usually antipatterns have more to do about inefficent structure of operating, or major pitfalls.
With antipatterns it’s not if something can work, you should ask if it would be reasonable for you to do so.
Are Anti-patterns always bad?
Like most things, sticking with a hard extreme is a bad thing to do. I think it should be considered to be more of an example of a thing to do as an absolute last resort. Is there absolutely no other way to go about doing what you’re doing? Go ahead. This assumes you can understand, accept the alternatives absolutely won’t work, document, have a future mitigation plan to move off of, explain and be prepared to justify what you’re doing. Even if you can pass through those exceptions, still consider taking a walk arround the park before moving forward.