Too Much Abstractions? Follow up
Too Much Abstractions? Follow up
I asked a question about how to know when you have too much
abstractions in your code? and do more abstractions implies better
design?
I promised to do a follow up post and give my humble opinion.
So here it goes.
As architect I’m using abstractions a lot. It allows me to hide the
implementation details and create API’s for my consumers. Also, it
lets me the ability to change the implementation at a later stage of
the project if I need to and of course it makes the code more testable.
One other thing about abstractions is that they decouple the code
we are writing which is a good thing to do. But as always with every
good there can be bad and we can abuse the use of abstractions.
One sentence that I used when I was consulting about
architecture at a customer was “too much abstractions will kill you”.
What I meant was that since we can abstract everything we need to
get the “feeling” when it is appropriate to use this method.
In the customer code there were abstractions on top of other
abstractions which provided less details or identical interface to what
they tried to abstract. So in this situation I preferred to follow the KISS
principle and remove some of the abstractions away. Now the solution is
clearer and more readable with less unneeded abstractions.
The customer’s example shows that even though abstractions are a good
practice you should understand were to apply them. For example to
abstract your infrastructure is a very good practice. Take a look at the
Enterprise Library or Spring.NET code to see how you can leverage
abstractions. On the other hand to create an interface to a Data Transfer
Object which abstract its properties is something that I’ll prefer to avoid.
The reason is that DTOs are meant to be data holders that have no
behavior. If I abstract the properties I gain nothing since in most cases
the implementation will be a getter and a setter and nothing more.
These two examples show exactly what I meant when I wrote that you
should understand were to apply abstractions.
In conclusion, there are times that we use too much abstractions in
our code. If an abstraction doesn't add any value you shouldn’t create it
because it will complicate your code. There is no such thing as abstractions
compass which can tell you when the abstraction is needed or not (or when
you have created too much abstractions). This is why I start with a simple
implementation and then refactor my code and create the needed
abstractions. As a last statement more abstractions don’t imply better
design.