Handling dependencies
Monday, April 12th, 2004Something which has paid off for me a couple of times so far, though only on individual projects and not on corporate team work projects where issues like never getting to refactor could come into play:
When starting a new project, let the dependencies run wild. Include Commons Lang because you’re too long-term-lazy to c+p yet another simple function in. Include log4j because you don’t want to be JDK 1.4 dependent. Basically, be chaotic.
Following the initial release, over which some will grumble about dependencies, have a crack-down on those dependencies when you find yourself next working on the code. There seem to be four ways of removing a dependency;
1) Remove the functionality. For example, throw out regular expression support.
2) Increase platform dependency. This is cheating basically, but utterly legal. Move from JDK 1.2 support to 1.4. A simple way to remove a log4j or jakarta-oro dependency.
3) Inline the code. I find myself doing this quite a lot when I depend on my genjava-core utils or Commons Lang/IO/Collections etc. Often it’s just the one method. An important thing to do in this case is make a note that it’s inlined so that later on in life the code may decide to regain the dependency due to the number of inlined methods.
4) Optional functionality. Make it a compile-time dependency, but allow the user to ignore that jar and still get the basic functionality. This one is the nicest one, but a bit of a pig for the user who wants the extra functionality. Must be clearly documented. Possibly you could write something dynamic to print out an error message frmo your library instead of the Java interpreter.
A fifth might be to create a common facade, ie) commons-logging, but this is really increasing your dependency list by trying to be tidier.
