in Academic, Coding

Anti Patterns

A couple of days ago I have been to a tech talk from eBay in Berlin. The talk was hold by a developer of the eBay Kleinanzeigen team (a subsection of eBay in Germany) who talked about development patterns his team learned during the years. He mentioned behavioral patterns, design patterns and coding pattern his colleagues and he discovered as good practices for their projects. Since nearly everything could be seen as a pattern, the talk was a mix of learned lessons and actual advises on how to structure code. Cool! It is always good to talk and hear about coding experiences and it also reminded me at something which is often more important than patterns: anti patterns!

2015-01-22 19.27.11

The idea of anti patterns always comes to my mind when I’m reading some old code. And it comes more often if the code is super sophisticated and fancy. The more people try to engineer their code, the more they build things which looks like some complicated pattern but are actually anti patterns.

You like some examples? Here’s a very trivial anti pattern, not a big thing. It’s just a bad habit. It looks like that:

Anything wrong here? No, just a factory. Anything useless? Yes, a little bit. It’s very likely to see a class with only static methods (like a factory) to have a private constructor. Why? Because the developer thought it’s evil to instantiate it and he must prevent it for the safety of everybody in the room! So he creates something which look like a singleton (but isn’t). He does this in every suitable class, because it’s his patterns. But it is actually nothing. What would happen if you instantiate such an object? Nothing. And if you call static methods on that object? Nothing, too. It doesn’t look good, but it would work and your IDE would warn you. So what problem does it solve? There’s none. It just looks like some useful pattern, but actually does nothing but clutter your code. An anti pattern.

There are more of those small bad habits (like using final everywhere) but also bigger ones (like an interface for everything). I’m going to think about this a little more and come up with another example!

Best regards,

Write a Comment


  1. Actually, some IDEs will tell you to add the private constructor. It makes it unambiguous that the only methods this class can use are static ones.

    I fail to see how making a field final where it can be is an anti-pattern.

    • Because what’s the point of adding more entropy on top of a pile of entropy? This is like saying “my room is a pig-pile I no longer see the floor anymore. So what’s the deal if I just leave one dirty dish on top of it all.”

  2. In general, I fail to see what’s the problem with using final everywhere (in particular parameters.) The only problem is when people try to create immutable objects in a language (Java) that by default has no support for such a concept.

    In other languages immutability is the default so that just solves a whole class of bugs. And in C/C++ I simply default to declare everything const (which solves a whole class of even harder to fix bugs.)