@ImplementedBy madness
Consider a codebase of considerable size, thus being open-source.
This codebase uses Google Guice to wire its innards together. Last time I looked, it had a central FoobarGuiceModule which listed all of the classes wired together. When I integrated that codebase into $DAYJOB, I wrote a DayjobGuiceModule to manage the things different for me. No biggie. I knew where to look, in a single place.
Three months later, the FoobarGuiceModule is all but gone. Instead, the authors decided to sprinkle the most unfortunate decision ever made by the Guice authors (maybe this is where the nickname comes from) over the code: @ImplementedBy.
Instead of one (or maybe a few, when the code is not monolithic, let’s say three) place where the configuration is centralized, it is now spread out over 32 (!) (that is thirty-two) different interfaces which all happily tell you that they are implemented by someone else. Including a few that chirp out that they are implemented by demo-code that you want to override lest you will not be able to integrate the code into your own stuff.
Oh, and you must follow the project from SVN. It has no release yet (even though it is almost a year now in open source).
Maintenance nightmare. If you have a different opinion, let me know. I would be happy to hear a good justification for @ImplementedBy. Or, in the words of Bob Lee:
“@ImplementedBy is an experts only feature; it’s not for everybody. You have to weigh the benefits and consequences in context. @ImplementedBy may not be as robust as a completely separate interface, but it is more concise, and it’s better than depending directly on a concrete class. If you’re only using an interface to simplify unit testing, @ImplementedBy is a perfectly pragmatic compromise.”
Leave a Reply