Following are a number of paragraphs stripped from "Spring in Action, 2nd Edition" ,by Craig Walls, published by Manning Publications in 2007, which illustrate in a rather friendly manner the ups and downs when opting for a particular type of mutator: [This goes in my blog as a future reference]
"There are certain things that most people can agree upon: the fact that the sky
is blue, that Michael Jordan is the greatest player to touch a basketball, and that
Star Trek V should have never happened. And then there are those things that
should never be discussed in polite company, such as politics, religion, and the
eternal “tastes great/less filling” debates.
Likewise, the choice between constructor injection and setter injection stirs up
as much discourse as the arguments surrounding creamy versus crunchy peanut
butter. Both have their merits and their weaknesses. Which should you choose?
Those on the constructor-injection side of the debate will tell you that:
• Constructor injection enforces a strong dependency contract. In short, a
bean cannot be instantiated without being given all of its dependencies. It is
perfectly valid and ready to use upon instantiation. Of course, this assumes
that the bean’s constructor has all of the bean’s dependencies in its param-
eter list.
• Because all of the bean’s dependencies are set through its constructor,
there’s no need for superfluous setter methods. This helps keep the lines of
code at a minimum.
• By only allowing properties to be set through the constructor, you are, effec-
tively, making those properties immutable, preventing accidental change in
the course of application flow.
However, the setter injection-minded will be quick to respond with:
• If a bean has several dependencies, the constructor’s parameter list can be
quite lengthy.
• If there are several ways to construct a valid object, it can be hard to come
up with unique constructors, since constructor signatures vary only by the
number and type of parameters.
• If a constructor takes two or more parameters of the same type, it may be
difficult to determine what each parameter’s purpose is.
• Constructor injection does not lend itself readily to inheritance. A bean’s con-
structor will have to pass parameters to super() in order to set private
properties in the parent object.
Fortunately, Spring doesn’t take sides in this debate and will let you choose the
injection model that suits you best. In fact, you can even mix-and-match construc-
tor and setter injection in the same application... or even in the same bean."
"There are certain things that most people can agree upon: the fact that the sky
is blue, that Michael Jordan is the greatest player to touch a basketball, and that
Star Trek V should have never happened. And then there are those things that
should never be discussed in polite company, such as politics, religion, and the
eternal “tastes great/less filling” debates.
Likewise, the choice between constructor injection and setter injection stirs up
as much discourse as the arguments surrounding creamy versus crunchy peanut
butter. Both have their merits and their weaknesses. Which should you choose?
Those on the constructor-injection side of the debate will tell you that:
• Constructor injection enforces a strong dependency contract. In short, a
bean cannot be instantiated without being given all of its dependencies. It is
perfectly valid and ready to use upon instantiation. Of course, this assumes
that the bean’s constructor has all of the bean’s dependencies in its param-
eter list.
• Because all of the bean’s dependencies are set through its constructor,
there’s no need for superfluous setter methods. This helps keep the lines of
code at a minimum.
• By only allowing properties to be set through the constructor, you are, effec-
tively, making those properties immutable, preventing accidental change in
the course of application flow.
However, the setter injection-minded will be quick to respond with:
• If a bean has several dependencies, the constructor’s parameter list can be
quite lengthy.
• If there are several ways to construct a valid object, it can be hard to come
up with unique constructors, since constructor signatures vary only by the
number and type of parameters.
• If a constructor takes two or more parameters of the same type, it may be
difficult to determine what each parameter’s purpose is.
• Constructor injection does not lend itself readily to inheritance. A bean’s con-
structor will have to pass parameters to super() in order to set private
properties in the parent object.
Fortunately, Spring doesn’t take sides in this debate and will let you choose the
injection model that suits you best. In fact, you can even mix-and-match construc-
tor and setter injection in the same application... or even in the same bean."
No comments:
Post a Comment