Thread by @tjaskula

My Friday rant about abstractions' design or rather how abstractions are seen by most of the developers myself included 😅

We often think about abstractions in terms of "what it is" but the important part that we often forgot about is to think in terms of "what it is not".

This is about finding the right balance between the concretness (more close to the implementation) and the abstractness (so abstract that it looses its meaning) of such abstraction.

In both extremes such abstractions are pretty useless.

Finding the right balance between concreteness and power is a difficult exercise and there is no a recipe we can follow. It depends on the domain problem and the experience of the modeler.

Obviously the more abstraction is concret the less things it can represent.

The more abstraction is abstract the more you have to sacrify things you know about until the point that it's loosing its meaning.

Because there is a reality behind the abstraction. The concrete implementation must satisfy the constraints so that client can use it without fear.

Let's try to find some examples of the problems when you go down the path of making an abstraction too concrete. We said that if it's too concrete there is few things it can be used as abstraction for.

Being familiar with .NET world I saw interfaces like ISqlRepository

Interface supposed to be an abstraction of course. But this interface leaks already what kind of concrete implementation it abstracts; SQL.

What is the point of such abstraction at all ?

It is too close to the implementation so almost useless.

The better name would be IRepository. However there is trap. Is it really easy to define a common set of properties for such an abstraction ?

Do Sql and EventSourced implementation can be described in terms of the same abstraction for a repository. Seems like its not that easy

Now let's take an example of an abstraction that may be too abstract.

We said that either we must sacrify the properties we know about concrete implementation to build a more powerful abstraction, or to keep those properties with a risk of breaking Liskov Substitution principle

The problem of sacrifying the properties may be that making a concrete implementation will be too hard. Breaking LSP, it's a design choice but it has its own consequences.

Let's take an example from .NET. Everybody has already used an abstraction like IDictionary<TKey, TValue>

It happens that different implementation can have different constraints in terms of writing. If you expect an IDictionary, you are supposed to read from it and Add new elements in.

But what if the concrete implementation is and ImmutableDictionary ?

Trying to Add a value in will throw NotSupportedException. So it definitely breaks LSP and breaks the client working with that abstraction, that should not be interested upon the concrete implementation.

Similar design choices where made in .NET framework for IList<T> interface

It's not good or bad. It's a trade-off to find the right balance.

So IList<T> encourages creating types that are not substitutable for each other, breaking LSP. Such types you have to check the state of flags to determine which implementation one is handling.

But there was a trade-off going down the "purity" path or favor usefulness so I think the pragmatic decision was taken in its design.

I have given some examples from OOP world, but believe me FP design has exactly the same problems of choosing the right level of abstraction.

If you consider a function as one method interface, it's a kind of abstraction on its own.

Choosing wisely the right level of abstraction is hard. It has implications whatever direction you take.

To find a better balance consider what an abstraction "is" and what "it is not"