Abstracting Abstractness into Abstract Abstractness of Abstracted Abstratness
time to read 2 min | 353 words

Do worry about the title, it isn't meant to say anything meaningful.

Ted Neward had posted about the OSS WebCast, and one thing caught my eye:

... Scott had mentioned that Corillian (his company) had built an abstraction layer on top of the open-source logging package, log4net. This reminded me so strongly of Commons Logging that I made a comment to that effect, warning that the Java community got itself into trouble (and continues to do so to this day, IMHO) by building abstraction layers on top of abstraction layers on top of abstraction layers, all in the name of "we might want or need to change something... someday"...

I am quite passionate about squashing this tendancy whenever I find it. There is value in abstracting a complex library to a simple set of API, but abstracting the library just because you don't want a dependency is going to bite you.

First, your API is going to be limited, since you can't make advantage of everything that the library has to offer, and you can't just upgrade the library and start using the new features, since you need to decide beforehand if you can the abstraction layer.

Second, API isn't the only thing that cause a depenedency. It is the interactions between your code and the library that cause the dependency. To give a simple example, log4net will never throw an exception, the Logging Block from Microsoft will happily throw an exception if it can't log, which will kill you application, since you assumed that an exception cannot be thrown from logging calls.

I don't even really like the logging services in Castle, for exactly this reason. But in this case, we does have users that need both NLog and log4net, so at least we are dealing with abstracting abstractions into nothingness

Tweet Share Share 0 comments
Tags: