Idea: poorly injected dependencies inspection

I had an idea for an inspection. Let's say I have some UglyClass with 30 public
methods. Now I have UserClass which takes an instance of UglyClass as
constructor, and stores it in a field. However, UserClass only uses 2 of those
30 methods. I think this shows that it's time to extract an interface. An
inspection could pretty easily find this.

What do you guys think? I don't use Dependency Injection things like
picocontainer, so maybe people who have experience with that will have some
ideas for this inspection.

Comment actions Permalink

This is a good idea, but what would be the threshold to warn about extracting an interface (50% unused methods? 30%?)? And what if the injected object already has an interface?

Most often than not, I have "repository" services that take care of loading and saving objects from/to a relational store; depending on the complexity of the said object, these repositories can have as few as 4 methods (find by ID/find all/save/delete) to as many as 15~20 methods (different load criterias and depth). Either way, a single web/swing action will use only one or two of these methods. Would this be a case for your "poor DI" inspection?

Comment actions Permalink

More thinking about the subject: a simple and generally correct inspection would be to warn about any concrete (i.e., not an interface) injection.

There's only one justified use case for concrete injections I can think about right now: "config objects", i.e., an object with lots of simple properties, put together to simplify configuration. It wouldn't be too hard to exempt this kind of objects from the inspection, anyway: we could just check if the injected class is composed of getters and setters alone, and nothing else.


Please sign in to leave a comment.