Finding someone else's class names in your app
A developer I work with made the comment that, “Seeing someone else’s company name in your code is a smell.”
That’s pretty darn good wisdom. Isolating the parts of your app most likely to change from those that are stable could be one of the best heuristics for maintaining a growing app. It’s good design and is the subject of the metrics from the churn gem. This kind of proxy class can also make testing easier. You can add test-env specific code, or stub methods in your app instead of on a gem (horrors).
So…next time you add a gem to your application, take a few moments to consider whipping up a proxy class that hides the gem’s classes. The easiest way to do this is to delegate directly to the gem’s methods using the same method names. You could think about using my favorite toy, #delegte, in Rails, but sometimes the simplest thing works great.
As an example, I recently implemented the fantastic stats tracking tool InstrumentalApp. Instead of referencing their gem directly throughout my code, I wrapped it up, making a change to another stat tracking library easier down the road:
While we could get cute with Ruby and do some #method_missing and *args, I think it’s better to be explicit with our proxy class. List the exact methods you will support long-term (since you’ll need to keep them around if you switch libraries) and with what arguments.
So take a look through your app. Where are you using the class name of a gem when you should consider wrapping their class with your own?
Published November 30, 2012