Can we have too many abstractions in a codebase?

Last Update: 23.04.2018. By Jens in Developers Life | Learning | Newsletter

Sounds like a simple question, but is it?

I am using the project from stone age as an example again. For the new readers, it is a 15+ years old collection of Java systems, failed refactors, etc. and I can’t give details (NDA). However, abstract concepts are fine. So bear with me.

Anyway, today’s topic is abstractions.

In the center we have a module with the core functionality, let’s name it core. The next one is a simple adapter to the core for a specific reason. we come to the reason in a moment And another one with a couple of web services. The core is used in multiple individual applications or a mashup-application, it is one doing too much for different use cases.

Traditionally, devs should care for module boundaries and should not expose internal implementations. It’s what they have done here too. So, in the worst case, we could end up with 3 times the same data class, in each module one. Between the adapter and the core the data classes usually differ, but between the adapter and the web service responses not really. The ones I checked contained the same information.

The result of this is, that it makes it exceptionally hard to understand and navigate the code. Also, because they added too many god classes in the web service and adapter. For a simple request it looks like:

Webservice -> transform input to ws model -> transform request to adapter model -> adapter magic (am) -> calling core -> am builds response -> transform am response to ws model -> transform ws model to response

At first glance you might say, where is the problem?

That’s a good question.

In this concrete example, it’s raising the noise and complexity. The three modules alone already contain hundreds of classes. Adding an extra layer of noise does not help. But it is a common way devs handle legacy systems. Adding a new layer. Fast-forward a few dev generations and the mess is perfect.

Tomorrow I’ll tell you the story why the adapter exists in the first place.