Can too much abstraction be bad?

Question

As programmers I feel that our goal is to provide good abstractions on the given domain model and business logic. But where should this abstraction stop? How to make the trade-off between abstraction and all it's benefits (flexibility, ease of changing etc.) and ease of understanding the code and all it's benefits.

I believe I tend to write code overly abstracted and I don't know how good is it; I often tend to write it like it is some kind of a micro-framework, which consists of two parts:

1. Micro-Modules which are hooked up in the micro-framework: these modules are easy to be understood, developed and maintained as single units. This code basically represents the code that actually does the functional stuff, described in requirements.
2. Connecting code; now here I believe stands the problem. This code tends to be complicated because it is sometimes very abstracted and is hard to be understood at the beginning; this arises due to the fact that it is only pure abstraction, the base in reality and business logic being performed in the code presented 1; from this reason this code is not expected to be changed once tested.

Is this a good approach at programming? That it, having changing code very fragmented in many modules and very easy to be understood and non-changing code very complex from the abstraction POV? Should all the code be uniformly complex (that is code 1 more complex and interlinked and code 2 more simple) so that anybody looking through it can understand it in a reasonable amount of time but change is expensive or the solution presented above is good, where "changing code" is very easy to be understood, debugged, changed and "linking code" is kind of difficult.

Note: this is not about code readability! Both code at 1 and 2 is readable, but code at 2 comes with more complex abstractions while code 1 comes with simple abstractions.

Answer 1

The very first words of The C++ Programming Language, 4th edition:

All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection. – David J. Wheeler

(David Wheeler was my thesis advisor. The quote without the important last line is sometimes called "The first law of Computer Science.")

Answer 2

Yes, definitely. The thing is, no abstraction is perfect. All of the details of the layer that abstractions sit atop are there for a reason, and it can simplify a lot of things, but if that complexity wasn't necessary at some point, it probably wouldn't be there in the first place. And that means that at some point, every abstraction is going to leak in some way.

And that's where the real problem lies. When abstractions fail, the more of them you have layered in between the code you wrote and what's actually going on, the harder it is to figure out the problem and fix it, because there are more places where the problem might be. And the more layers there are, the more you have to know in order to track it down.

Answer 3

Yes absolutely.

The analogy I like to use to explain programming is that of a Tailor. When making a suit, a good Tailor will always leave a small amount of fabric at strategic locations within the garment to allow the garment to be taken in, or out, without changing its overall shape or structure.

Good Tailor's don't leave reams of fabric at each seam just incase you happen to grow a third arm, or become pregnant. Too much material in the wrong places will make for an ill fitting, and ill wearing garment, the extra fabric simply gets in the way of normal use. To little fabric and the garment is prone to tears and will not be able to be altered to cope with minor changes to the physique of its wearer, effecting the way garment sits.

Perhaps one day, our Good Tailor will be tasked to make a dress so tight he has to sew its wearing into it. And perhaps our Good Tailor is asked to make maternity wear, where style and fit are second to comfort and expand-ability. But before undertaking either of those special jobs a good Tailor would be wise enough to make everyone aware of the compromises that are being made to achieve those goals.

Sometimes these compromises are the correct route to take, and people are willing to accept their consequences. But in most cases, the approach of leave a little where it counts the most will outweigh any perceived benefits.

So, relating this back to abstraction. Its absolutely possibly to have way too many layers of abstraction, just like its possible to have way to little. The true art of the programmer, like the our tailor friends, is to leave a little where it counts the most.

Getting back on topic.

The problem with code is usually not abstraction, but dependencies. As you've pointed out, its the code which connects discrete objects that's an issue, because there's an implicit dependency between them. At some point communication between things just needs to be concrete, but judging where that point is usually requires some guesswork.

That being said "Micro" anything is usually an indication that you've overgranulized your object layout, and are probably using Type as a synonym for what should be Data. Having less things also means less dependencies needed to communicate between them.

I'm a big fan of asynchronous messaging between systems for this reason. You end up with two systems dependent on the message, rather than each other. Giving you less tight coupling between communicating systems. At that point, if you need to have a dependency between systems you need to consider whether you've got the bits that are dependent in the right place(s). And its often the case that you dont.

Finally, complicated code is going to be complicated. There's often no way around that. But code which has less dependencies is far easier to understand than one which relies on various external states.

Answer 4

I feel that our goal is to provide good abstractions on the given domain model and business logic.

I have a different view: our goal is to solve a business problem. Abstractions are just a technique to organize a solution. Another answer uses the analogy of a tailor making clothes. I have another analogy I like to think of: a skeleton. The code is like a skeleton, and abstractions are the joints between bones. If you have no joints, then you just wind up with a single bone that cannot move at all and is useless. But if you have too many joints, you wind up with a pile of sloppy jelly that can't stand up on its own. The trick is to find the right balance -- enough joints to allow for movement, but not so much that there's no actual defined shape or structure.

Answer 5

One thing that hasn't been mentioned so far is the KISS principle and YAGNI: Keep it simple and stupid; You aren't gonna need it.

Sometimes, there are very good reasons for abstractions:

• You are already using them and you need them already to keep the complexity low - not maybe sometime in future, but actually already now.
• You're writing a library / something with a plug-in system and you want to prevent breaking changes for your users.

If it's not that, then maybe you can remove the abstractions.

Answer 6

I often see developers jumping into several levels of abstraction immediately, which I don't subscribe too. I always make a simple implementation first... enough to satisfy the requirements of the software... maybe with some re-use in mind, but simple. Then as a program evolves, or as the same requirement arises in another project.. I can always break it out into a separate re-usable chunk, further abstracted.
As an example, you're working on a program that needs to create several PDF reports.... do to this you go grab some shared library out there. Now, hopefully the library has already been abstracted out well.. so why do you need to abstract it out 3 classes deep, each with one method, to use it for that one purpose? Just wrap its functionality in a local library you have and use it directly in there. Later if necessary, not only can you add the additional abstraction, but when the need arises it paints a better picture of how the re-use and encapsulation should be implemented. This also acts like insurance against wasting time on planning for re-use that never happens. Sometimes you absolutely know you are going to want to reuse a feature, and when developing coding-tools or re-usable projects, you want to start out with a little more than a simple implementation... but you still might find it was wasted time.

Answer 7

There is one point where you recognise too much abstraction (there are probably others): When you are shown an interface, you read it, and you have no idea what it is doing and why you would use it, that’s too much abstraction.