Too Many Abstractions? Follow Up

Introduction

I asked a question about how to know when you have too many abstractions in your code? And do more abstractions imply better design? I promised to do a follow up post and give my humble opinion. So here it goes...

As an architect, I'm using abstractions a lot. It allows me to hide the implementation details and create APIs for my consumers. Also, it gives 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 abstraction will kill you”. What I meant was that since we can abstract everything, we need to get the “feeling” of 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 where 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 abstracts 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 where to apply abstractions.

In conclusion, there are times that we use too much abstraction 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 many 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.