How to identify that code is over abstracted?

Question

What should be the measures that should be used to identify that code is over abstracted and very hard to understand and what should be done to reduce over abstraction?

Answer 1

"Simplicity over complexity, complexity over complicatedness"

So - there's a benefit to abstract something only if You are "de-leveling" complicatedness to complexity. Reasons to do that can vary: better modularity, better encapsulation etc.

Identifying over abstraction is a chicken and egg problem. In order to reduce over abstraction You need to understand actual reason behind code lines. That includes understanding idea of particular abstraction itself (in contrast to calling it over abstracted cause of lack of understanding). And that's not enough - You need to know a better, simpler solution to prove that it's over abstracted.

If You are looking for tool that could do it in Your place - look no more, only mind can reliably judge that.

Answer 2

I will give an answer that will get a LOT of down votes!

If the code is written in an OO language .. it is necessarily heavily over-abstracted. The purer the language the worse the problem.

Abstraction should be used with great caution. If in doubt always use concrete data structures. (You can always abstract later, this is easier than de-abstraction :)

You must be very certain you have the right abstraction in your current context, and you must be very sure that concept will stand the test of change. Abstraction has a high price in performance of both the code and the coder.

Some weak tests for over-abstraction: if the data structure is a product type (struct in C) and the programmer has written get and set method for each field, they have utterly failed to provide any real abstraction, disabled operators like C increment, for no purpose, and simply not understood that the struct field names are already the abstract representation of a product. Duplicating and laming up the interface is not a good idea.

A good test for the product case is whether there exist any data invariants to maintain. For example a pair of integers representing a rational number is almost sufficient, there's little need for any abstraction because all pairs are valid except when the denominator is zero. However for performance reasons one may choose to maintain an invariant, typically the denominator is required to be greater than zero, and the numerator and denominator are relatively prime. To ensure the invariant, the product representation is encapsulated: the initial value protected by a constructor and methods constrained to maintain the invariant.

To fix code I recommend these steps:

1. Document the representation invariants the abstraction is maintaining

2. Remove the abstraction (methods) if you can't find strong invariants

3. Rewrite code using the method to access the data directly.

This procedure only works for low level abstraction, i.e. abstraction of small values by classes.

Over abstraction at a higher level is much harder to deal with. Ideally you'd refactor the code repeatedly, checking to see after each step it continues to work. However this will be hard, and sometimes a major rewrite is required, rather than a refinement. It's probably not worth it unless the abstraction is so far off base it is not tenable to continue to maintain it.