If you have to deal with legacy code (and we all do) one of the standard techniques to deal with it is to hide it behind a layer of abstraction.
While this is a valid pattern that helps in many cases, it comes with its own anti pattern.
I call it Legacy in an Onion.
It's what happens when every generation of developer considers whatever they find to be horrible legacy code.
So they create a layer of abstraction. The next generation considers the abstraction to be legacy and adds another layer of abstraction.
After a couple of generations all the different layers start to cause serious problems when trying to understand the code and possibly even when executing it.
So the next time you encounter legacy code and want to add a layer of abstraction, rub the legacy code a little. Maybe you can peel of a layer of abstraction. If you find such a layer, you have multiple options:
Improve it so it fits your needs
Replace it with your layer
Directly work with the stuff below the layer
Just don't add a layer of abstraction just for the sake of adding a layer of abstraction.
Wan't to meet me in person to tell me how stupid I am? You can find me at the following events:
- Spring Data JDBC - New Kid on the block.
- Softwaredevelopment in the 21st century.
- Domain Driven Design mit Relationalen Datenbanken und Spring Data JDBC.
- Kerbal Space Program, Glücksspiel und Psychologie und was das mit dem (Berufs)leben zu tun hat.
- Javaland Freeletics
- Domain Driven Design mit relationalen Datenbanken und Spring Data JDBC
- The New Kid on the Block: Spring Data JDBC