El dom, 17-05-2009 a las 15:17 -0700, Igor Vaynberg escribió:
> IOC works fine if you use constructor injection :) which is what you
> should use. 
+1

Tor Iver, take a look at http://misko.hevery.com/code-reviewers-guide/
It is a very good reading! 

> the only reason people may prefer setter injection is that
> configuration looks nicer.
> 
> <param name="service" ref="some.service"/>
> 
> looks a lot nicer then
> 
> <constructor-arg index="2" ref="some.service"/>
> 
> -igor
> 
> On Sun, May 17, 2009 at 2:50 PM, Wilhelmsen Tor Iver <toriv...@arrive.no> 
> wrote:
> >> 2 - A constructor is for constructing - your object should
> >> not be in an incomplete state when the constructor is
> >> finished (such a state that methods such as isVisible can not
> >> be called)
> >
> > Tha language ensures that the object is "complete" when the constructor
> > exits, but with the exception of immutalbe objects, as a "component" it
> > is not complete. People are e.g. adding to lists at runtime, leading to
> > possible "subcomponent initialiation" later on in the relevant method of
> > a Loop or ListView for instance. It could also be argued for instance
> > that a LoadableDetachableModel is /intentionally/ "incomplete" when the
> > constructor exits. Overriding methods like isVisible() is also a form of
> > "hack" to postpone a property value to a later time (basically the
> > component stops having a "real" property called visible since the setter
> > modifies a variable that the getter does not care about).
> >
> > The desire to have "completeness" after constructor completion also runs
> > afoul with modern ideas like IoC where it is left to an outside agent to
> > complete configuration of a component.
> >
> > However, I agree that the attention of the thread originator should be
> > on the models.
> >
> > - Tor Iver
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Reply via email to