Setter injection vs Constructor Injection with example

use constructor injection for all mandatory collaborators and setter injection for all other properties. Again, constructor injection ensures all mandatory properties have been satisfied, and it is simply not possible to instantiate an object in an invalid state (not having passed its collaborators). In other words, when using constructor injection you do not have to use a dedicated mechanism to ensure required properties are set (other than normal Java mechanisms).
One of the other arguments for not using constructor injection is the lack of argument names in constructors and the fact that these do not appear in the XML. I would argue that in mostapplications, this does not matter that much. First consider the variant that uses setter injection:

<bean id="authenticator" class="com.mycompany.service.AuthenticatorImpl"/>

<bean id="accountService" class="com.mycompany.service.AccountService">
  <property name="authenticator" ref="authenticator"/>
</bean>
This version mentions the authenticator as a property name as well as a bean name. This is the pattern that I frequently encounter. I would argue that while using constructor injection, the lack of constructor argument names (and those not appearing in XML), doesn’t really confuse us a lot.

<bean id="authenticator" class="com.mycompany.service.AuthenticatorImpl"/>

<bean id="accountService" class="com.mycompany.service.AccountService">
  <constructor-arg ref="authenticator"/>
</bean>

Comments

Post a Comment

Popular posts from this blog

EJB - Stateful vs Stateless

For  stateless session beans  the server can maintain a variable amount of instances in a pool. Each time a client requests such a stateless bean (e.g. through a method) a random instance is chosen to serve that request. That means if the client does two subsequent requests it is possible that two different instances of the stateless bean serve the requests. In fact there is no conversational state between the two requests. Also if the client disappears, the stateless bean does not get destroyed and can serve the next request from another client. On the other hand a  stateful session bean  is closely connected to the client. Each instance is created and bounded to a single client and serves only requests from that particular client. So happens that if you do two subsequent requests on a stateful bean, your request will be served always from the same instance of the bean. That means you can maintain a conversational state between the requests. At the end of the li...
Read more

Mirror binay tree - Java

public class TreeNode {     private TreeNode left;     private TreeNode right;     private Object value;     public TreeNode getLeft() {         return left;     }     public TreeNode setLeft(TreeNode left) {         this.left = left;         return this;     }     public TreeNode getRight() {         return right;     }     public TreeNode setRight(TreeNode right) {         this.right = right;         return this;     }     public Object getValue() {         return value;     }     public TreeNode setValue(Object value) {         this.value = value;         return this;     } } public class Mirror {     public stat...
Read more