In an object-oriented program: How much abstraction is too much? How much is just right?
I have always been a nuts and bolts kind of guy. I understood the concept behind high levels of encapsulation and abstraction, but always felt instinctively that adding too much would just confuse the program.
I always tried to shoot for an amount of abstraction that left no empty classes or layers. And where in doubt, instead of adding a new layer to the hierarchy, I would try and fit something into the existing layers.
However, recently I’ve been encountering more highly abstracted systems. Systems where everything that could require a representation later in the hierarchy gets one up front. This leads to a lot of empty layers, which at first seems like bad design. However, on second thought I’ve come to realize that leaving those empty layers gives you more places to hook into in the future without much refactoring. It leaves you greater ability to add new functionality on top of the old without doing nearly as much work to adjust the old.
The two risks of this seem to be that you could get the layers you need wrong. In this case one would wind up still needing to do substantial refactoring to extend the code and would still have a ton of never used layers. But depending on how much time you spend coming up with the initial abstractions, the chance of screwing it up, and the time that could be saved later if you get it right – it may still be worth it to try.
The other risk I can think of is the risk of over doing it and never needing all the extra layers. But is that really so bad? Are extra class layers really so expensive that it is much of a loss if they are never used? The biggest expense and loss here would be time that is lost up front coming up with the layers. But much of that time still might be saved later when one can work with the abstracted code rather than more low-level code.
So when is it too much? At what point do the empty layers and extra “might need” abstractions become overkill? How little is too little? Where’s the sweet spot?
Are there any dependable rules of thumb you’ve found in the course of your career that help you judge the amount of abstraction needed?
I don’t think there is a definitive answer to these questions. Experience is needed to develop a feeling of what is “too much” and “too little”. Maybe the usage of some metric or quality control tools can help, but it’s hard to generalize. It mostly depends on each case.
Here are a few links that might inspire you in the quest of answers:
Development is all about finding the right balance between the various tensions that are present in any software engineering effort.