<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Constructor Injection vs. Setter Injection</title>
	<atom:link href="http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/feed/" rel="self" type="application/rss+xml" />
	<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/</link>
	<description>Testability Explorer</description>
	<lastBuildDate>Tue, 09 Mar 2010 04:29:26 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Craig Harris</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-2713</link>
		<dc:creator>Craig Harris</dc:creator>
		<pubDate>Sat, 02 Jan 2010 02:40:22 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-2713</guid>
		<description>@Artur,

The builder pattern would appear to solve many of the problems you are seeing.</description>
		<content:encoded><![CDATA[<p>@Artur,</p>
<p>The builder pattern would appear to solve many of the problems you are seeing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: misko</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-2709</link>
		<dc:creator>misko</dc:creator>
		<pubDate>Fri, 01 Jan 2010 17:59:58 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-2709</guid>
		<description>@Artur,

Yes too many arguments in your constructor is a code smell. It means that your object has too many responsibilities and needs to be broken up.</description>
		<content:encoded><![CDATA[<p>@Artur,</p>
<p>Yes too many arguments in your constructor is a code smell. It means that your object has too many responsibilities and needs to be broken up.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Artur Ejsmont</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-2687</link>
		<dc:creator>Artur Ejsmont</dc:creator>
		<pubDate>Wed, 30 Dec 2009 16:59:14 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-2687</guid>
		<description>Hi there

Im not sure yet how much i like constructor injection but i know i dont like setter injection. You should not be able to create non functioning object. Init methods and magic calls needed to make instance work are code smell as well i would say.

The problem i would agree with is that in constructor injection you have no clear names for parameters (in some frameworks only order tells you what to insert) and if you have too many of them code begins to look bit nasty.</description>
		<content:encoded><![CDATA[<p>Hi there</p>
<p>Im not sure yet how much i like constructor injection but i know i dont like setter injection. You should not be able to create non functioning object. Init methods and magic calls needed to make instance work are code smell as well i would say.</p>
<p>The problem i would agree with is that in constructor injection you have no clear names for parameters (in some frameworks only order tells you what to insert) and if you have too many of them code begins to look bit nasty.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Berlin Brown</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-2630</link>
		<dc:creator>Berlin Brown</dc:creator>
		<pubDate>Fri, 18 Dec 2009 15:31:18 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-2630</guid>
		<description>This is probably a stupid question, but how do you deal with constructor injection and too many arguments.  Should we create everything and the kitchen sink objects and then pass that as our constructor?</description>
		<content:encoded><![CDATA[<p>This is probably a stupid question, but how do you deal with constructor injection and too many arguments.  Should we create everything and the kitchen sink objects and then pass that as our constructor?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: firefight</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-1404</link>
		<dc:creator>firefight</dc:creator>
		<pubDate>Wed, 15 Jul 2009 19:26:47 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-1404</guid>
		<description>Nice article. I think the problem with your view of setter injection is that you have &quot;reasonable defaults&quot;.  With Spring you do not have any reasonable defaults, they are null by default, so your app will fail quickly and obviously, rather then appear to work, if the setters are not called. It sounds like you were doing all of the setting in code once per object, rather then specifying them once per class, like you do in Spring.

Personally I&#039;m not fond of setter injection, either. I like my objects immutable if possible, and it just seems like a lot of extra code and configuration, that is rarely ever used to extend the application anyway.</description>
		<content:encoded><![CDATA[<p>Nice article. I think the problem with your view of setter injection is that you have &#8220;reasonable defaults&#8221;.  With Spring you do not have any reasonable defaults, they are null by default, so your app will fail quickly and obviously, rather then appear to work, if the setters are not called. It sounds like you were doing all of the setting in code once per object, rather then specifying them once per class, like you do in Spring.</p>
<p>Personally I&#8217;m not fond of setter injection, either. I like my objects immutable if possible, and it just seems like a lot of extra code and configuration, that is rarely ever used to extend the application anyway.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Constructor Injection vs Setter Injection &#171; shaun smith</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-937</link>
		<dc:creator>Constructor Injection vs Setter Injection &#171; shaun smith</dc:creator>
		<pubDate>Fri, 01 May 2009 17:56:41 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-937</guid>
		<description>[...] Constructor Injection vs Setter Injection Constructor vs Setter Injection - Constructor is Better Setter injection versus constructor injection and the use of required [...]</description>
		<content:encoded><![CDATA[<p>[...] Constructor Injection vs Setter Injection Constructor vs Setter Injection &#8211; Constructor is Better Setter injection versus constructor injection and the use of required [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Using (These) Anonymous Inner Classes is Probably Too Clever for Your Own Good at JAW Speak</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-759</link>
		<dc:creator>Using (These) Anonymous Inner Classes is Probably Too Clever for Your Own Good at JAW Speak</dc:creator>
		<pubDate>Wed, 11 Mar 2009 04:33:14 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-759</guid>
		<description>[...] It uses setters. Setters allow your object to be constructed in an inconsistent state. There are some situations setters are fine (i.e. form backing objects) but often your code is more clear without setters. In this particular case the setters aren&#8217;t egregious, but I still consider them a smell and much more verbose way that constructor injection. Read more about the problem with setter injection here [...]</description>
		<content:encoded><![CDATA[<p>[...] It uses setters. Setters allow your object to be constructed in an inconsistent state. There are some situations setters are fine (i.e. form backing objects) but often your code is more clear without setters. In this particular case the setters aren&#8217;t egregious, but I still consider them a smell and much more verbose way that constructor injection. Read more about the problem with setter injection here [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Integrazione JSF e Spring &#171; A Place In The Queue</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-730</link>
		<dc:creator>Integrazione JSF e Spring &#171; A Place In The Queue</dc:creator>
		<pubDate>Mon, 02 Mar 2009 19:41:19 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-730</guid>
		<description>[...] tramite costruttore, che personalmente preferisco rispetto all&#8217; approccio via setter. Questo articolo di Miško Hevery spiega i motivi della mia personalissima scelta :-)         &#171; [...]</description>
		<content:encoded><![CDATA[<p>[...] tramite costruttore, che personalmente preferisco rispetto all&#8217; approccio via setter. Questo articolo di Miško Hevery spiega i motivi della mia personalissima scelta <img src='http://misko.hevery.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' />          &laquo; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Liam</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-715</link>
		<dc:creator>Liam</dc:creator>
		<pubDate>Sat, 21 Feb 2009 01:20:35 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-715</guid>
		<description>@cory
Misko gave a talk entitled &quot;The Clean Code Talks -- Inheritance, Polymorphism, &amp; Testing&quot; [1]
In a nut shell: 
- By moving new operators from constructors into factories and injecting dependencies into constructors and wiring.
- Using polymorphism for state dependant code.
- Removes the need for runtime checks in code.
If a parameter is in the constructor, it is of importance for the state of the class yet the null-ness state of the pointer can affect code for the class. If you are going to use a factory to call new operators and dependencies are then injected into this factory, then it has the appropriate knowledge and constructs accordingly. The factory should make the decision and possibly pass a mock object. Why pass a null? If you do then there is the possibility of code being littered with if(null pointer) then else ... conditions. If it is important enough to the construction of the class, then it is important enough to mock the object and producing a clean code base which is easy to test. 
[1]http://www.youtube.com/watch?v=4F72VULWFvc&amp;feature=channel_page</description>
		<content:encoded><![CDATA[<p>@cory<br />
Misko gave a talk entitled &#8220;The Clean Code Talks &#8212; Inheritance, Polymorphism, &amp; Testing&#8221; [1]<br />
In a nut shell:<br />
- By moving new operators from constructors into factories and injecting dependencies into constructors and wiring.<br />
- Using polymorphism for state dependant code.<br />
- Removes the need for runtime checks in code.<br />
If a parameter is in the constructor, it is of importance for the state of the class yet the null-ness state of the pointer can affect code for the class. If you are going to use a factory to call new operators and dependencies are then injected into this factory, then it has the appropriate knowledge and constructs accordingly. The factory should make the decision and possibly pass a mock object. Why pass a null? If you do then there is the possibility of code being littered with if(null pointer) then else &#8230; conditions. If it is important enough to the construction of the class, then it is important enough to mock the object and producing a clean code base which is easy to test.<br />
[1]http://www.youtube.com/watch?v=4F72VULWFvc&amp;feature=channel_page</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: igorbrejc.net &#187; Fresh Catch For February 20th</title>
		<link>http://misko.hevery.com/2009/02/19/constructor-injection-vs-setter-injection/comment-page-1/#comment-714</link>
		<dc:creator>igorbrejc.net &#187; Fresh Catch For February 20th</dc:creator>
		<pubDate>Fri, 20 Feb 2009 14:02:03 +0000</pubDate>
		<guid isPermaLink="false">http://misko.hevery.com/?p=386#comment-714</guid>
		<description>[...] Constructor Injection vs. Setter Injection [...]</description>
		<content:encoded><![CDATA[<p>[...] Constructor Injection vs. Setter Injection [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
