Abstractions

After reading this interesting article: Abstracting away and Abstracting into it made me think of an argument discussion with a friend regarding this very topic. I was under the belief that when I was implementing logging for my application I would be best off to create my own ILog interface. And then creating wrappers that would encapsulate either Log4Net or NLog. My motivation was that Log4Net for example provides 50+ methods that I didn't need and that I wanted something for my application with just 3 methods:

LogMessage, LogWarning, LogError

I also wanted something easy to mock and unit test. The fact that this is logging is interesting because it is so ubiquitous, meaning whichever way I go could by coupled to nearly every single class.

One way we can address the problem by merely keeping the usage on the outskirts of the application. A good example of this are IOC containers. It doesn't really matter which library we use as the client code will not use it directly. This might seem impossible with the logging example but there are techniques such as creating logging aspects (AOP) but we won't go into that here.

In hindsight I feel that I was wrong about some things but right about some other. I didn't need to abstract Log4Net due to testing needs. Log4Net does already have an ILog interface and this does make it mockable and testable. And even though it has 50+ methods to mock do you even need to bother? In a unit testing scenario your config is set up to just print to the console, no mocking needed. However addressing the 2nd problem of swapping our libraries, do you even need to? Even if you have a project that you plan will live for 5-10+ years Log4Net will probably out live it. Also this particular example the library is proven and well established.

Also by creating my own interface I really thought that this is all I would need now, but in future I end up needing more, and in time I will just duplicate the effort of the library I am abstracting. This will unfortunately create the same inevitability which is the more abstractions I leak the more I am implicitly tying myself to that library anyway and ultimately I will introduce a piece of functionality that only the one library will support and switching will be impossible.

Of course I have seen many times where companies and projects have heavily embraced and invested in library X and then due to fading support or features were forced to move to Y and requiring large portions of the code base to be re written. In the cases I mention even if we created an abstraction to either X or Y there were such fundamental differences between what these graphics libraries supported from each other that a common abstraction wasn't possible and would more than likely just water down our interfaces leaving very little point of using either of them.

In this case though it is important that we use certain patterns for development for instance if we were using a graphics library and using the MVC or MVP pattern, in this unlikelihood we certainly could just replace our views and keep all business logic in tact. Also patterns like AOP mentioned above.

So as long as the library provides ways to mock and unit test and unless you are using a new very experimental library you are probably better to abstract into.

This is my honest advice for best business value, of course if I was writing something for myself I would certainly add layers and abstractions, because its more fun, but that's another story...