So I’ve been doing a lot of work lately that uses XWork’s IOC container. I know it isn’t as full featured as Spring, but often one of the major complaints I hear about it isn’t that it doesn’t support all the features (AOP, etc), but rather that it requires “Aware” interfaces where Spring can auto-wire directly based on the presence of a setter.
I know, the aware stuff is definitely “clutter”, but it has some nice advantages that I recently become fond of during a major refactoring (changing all types of “Category” to “Skill”). Specifically, I changed a component from being named CategoryManager to SkillManager. Changing the setter, setCategoryManager(), was a simple refactoring in IDEA.
If I didn’t have the aware interfaces, I would have had to do a string find-and-replace, something I’m often much less comfortable with.
Does anyone else ever have trouble with this?
on Sep 9th, 2005 at 1:34 pm
*Aware interfaces are an abuse of interfaces. Metadata shouldn’t do into interfaces, it should go in annotations or an XML file.
on Sep 9th, 2005 at 1:37 pm
I think what you want to do is define interfaces based on business or system logic, rather than on container requirements — i.e. if you have a bunch of objects that are all filters, that have a method like:
boolean accept(Object o)
Then you might as well define an interface called Filter that defines the same method signature and have these objects all implement that method, then if you decide to make it so all your filters can take optional parameters later you can refactor it easily to
boolean accept(Object o, Object[] params)
But the point is that you shouldn’t HAVE to — having common interfaces like this should be drive by business or system logic, not container requirements.
on Sep 9th, 2005 at 2:02 pm
John, and Bo: this all sounds like very religous arguments. I’m always a bit cautious when I hear people say words like “should” and “should not”. The fact is that refactoring is easier when an interface is used as opposed to using XML configuration. When I look at the costs vs. benefit, I don’t see a lot of costs with “abusing” interfaces, but I do see some decent benefit.
on Sep 9th, 2005 at 8:59 pm
Patrick that’s very interesting, I had not thought of that before. It’s the kind of benefit that you don’t see in trivial test application, but that gets to be a big deal later when your app is huge. Hmm.
on Sep 10th, 2005 at 1:51 am
Well, it could be argued the other way round too: if making refactoring easier is the only thing you get, then maybe the cost of creating interfaces might be considered too high.
Also, note that the *Aware scheme implies singletons. For example, an action cannot be handed two DataSource’s if there’s only one DataSourceAware interface, whereas with setData1(DataSource) and setData2(DataSource) that would not be a problem.
Basically it seems to come down to strong vs weak typing. Using an *Aware interface makes it easy to see what actions require what. At the same time, it seems like using an annotation could do the same trick though, and with the benefit of being applicable to non-singleton resources/services.
on Sep 10th, 2005 at 3:30 am
You can achieve same level of refactoring-friendlines in Spring by using autowire=”byType”. That way Spring ignores names of the setters and uses only the type of the setter to figure out which object to inject. Since you don’t have to specify the names in XML, there’s no risk of getting them wrong. This would leave you with setters having funny names, though.
Of course this means that you can’t have several objects of same type. Then again, as Rickard pointed out, that’s a problem with *Aware interfaces as well.
Personally I don’t use autowire and let Spring IDE for Eclipse verify that nothing breaks when I refactor. I haven’t felt enough pain to justify having *Aware interfaces around. Your mileage may vary.