a simple basic java question here:
in our company code we develop a spring application and heavily use injection in our beans.
Several times in our beans we define interfaces as class members like in this excerpt from our application context:
<bean id="testDAO" class="it.dao.commerciale.TestDAO">
<property name="sessionManager" ref="sessionManager" />
<property name="iDAO" ref="testDAO" />
<property name="iService" ref="testService" />
</bean>
Then we have the corresponding members in our classes difined as private, togheter with getter and setter methods:
public class TestDAO implements ITestDAO {
private IService iService;
private IDAO iDAO;
public IDAO getiDAO() {
return iDAO;
}
public void setiDAO(IDAO iDAO) {
this.iDAO = iDAO;
}
}
It's something we are used to do, but now I'm starting to investigate why we do it.
What can be the utility in defining an interface as a private member of a class?
Moreover using the prefix "I" naming convention for interfaces seems to break Spring bean validation rules, since it complains about the absence of a setter that is obviously in place. If I remove the "I" prefix the error disappears.
EDIT after reading comment:
So for example if I have an Engine (as an Interface) I could put inside a class TruckEngine (that implements Engine) an Interface member "Radiator", that does not rely in a particular implementation of the radiator duties.
What about the validation prefix problem?
EDIT 2:
After reading dunni comment I found that the validation error was caused by the automatic getter/setter generation in Eclipse. In short if the property is named iPropertyName (with a 1-letter lowerscore prefix) the get and set methods will create a "getiPropertyName" with lowercase prefix, and this breaks the validation. I verified this on STS 3.8.1.
Thanks