Specializes In

Abstraction For The Sake Of Abstraction? Why Add Unneeded Complexity?

Leave it to Max Pool from Codesqueeze to introduce us to the concept of Premature Abstraction. And let’s face it, we are all guilty of it sometimes. Back when I started working with IOP and Spring we had abstraction crammed down our throats. EVERYTHING was an interface, and we were told to always code to interfaces rather than concrete classes.

There is nothing so useless as doing efficiently that which should not be done at all.

Don’t get me wrong. I love abstraction, and I employ it on a regular basis when developing software. But developing an abstract layer on top of a single concrete implementation because you “might” reuse the abstract code someday is in violation of the YAGNIprinciple. The main idea behind YAGNI is “If you need it, you can put it in later. If you don’t need it, you won’t have to do the work at all.”

If you follow any of the IOP or dependency injection tutorials out there you will notice that they almost always encourage you to create an interface, and then use dependency injection to inject a concrete implementation that interface into the using class. This does a great job of decoupling your code, and you can easily switch between concrete implementations by simple modifying a config file. But the problem arises when you only have one concrete implementation, or the code is naturally coupled. Now we have an overly complex model representing a fairly simple implementation.

Instead adding complexity without any benefit, code to the concrete implantation itself. Sure, you “might” need to create abstraction out of a class at some point to avoid repeating code. But until you actually need it, don’t do it. Just say No to abstraction purely for the sake of abstraction…