I don't have any input on the issue as it relates to Shiro, but fwiw, I feel the exact opposite as Bryan regarding dependency injection.
With constructor injection, you end up with zero additional "boiler plate" code and you know that your objects are setup once they're created instead of having separate "creation" and "initialization" steps. Anyways, probably a religious argument; just my $0.02 :) --Erik On Wed, May 12, 2010 at 11:29 PM, Bryan Turner <incomm...@hotmail.com>wrote: > > I'd like to jump in on this and say that I think both approaches have > value. There's little reason, in my opinion, why both can't be done. > add/remove methods do not necessarily preclude get/set methods; I think both > should be in the code for these sorts of framework pieces. > With regards to IoC and injection, I'll start by declaring my allegiance: I > _hate_ constructor injection and I remove it everywhere I can. That said, I > recognize that is offers an _appearance_ of better safety and that it has > its benefits and proponents. Constructor injection quickly swells to > unmanageable proportions when objects have many dependencies. This becomes > particularly onerous if many of those dependencies are optional > dependencies. Setter injection better expresses this: If you need a > component, set it; if you don't need it, don't set it. Supporting setter > injection out of the box seems like it provides the broadest overall avenue > of capability and seems, based on my experience with how people use IoC, > like it supports the desires of the greatest percentage of IoC users. > The important thing, to my mind, is that these setters not be on the > interfaces exposed by the objects. If abstract base classes and other > default implementations expose mutator methods built for initialization, so > long as the interface they are implementing does not have them, then those > mutators are not noise to the end user of the object. In that regard, I > agree with Kalle: It seems like add/remove semantics should be observed for > listeners in the interfaces. If the implementation includes setter methods > to support that style of injection, then that's hidden from consumers of the > object. > Just my two cents, and probably a bit out of the blue. But I've converted a > substantial portion of shiro-core to .NET, so I have a fairly experience > with the codebase. > Bryan Turner > > > Date: Wed, 12 May 2010 14:59:36 -0700 > > Subject: Re: r942498 - removing all convenience methods? > > From: kalle.o.korho...@gmail.com > > To: shiro-dev@incubator.apache.org > > > > On Wed, May 12, 2010 at 2:43 PM, Les Hazlewood <lhazlew...@apache.org> > wrote: > > > Agreed. And after working with all these getters/setters and trying > > > to figure out when it is safe to initialize things or not, I would > > > _REALLY_ love to use constructor injection for everything. > > > Unfortunately, for whatever reason or another, a lot of people seem to > > > really dislike using it :/ > > > > They just haven't seen the light yet :) > > > > > I guess its because there are scenarios where constructor injection > > > probably wouldn't be pleasant - think of how many permutations of > > > config options there are for dependency injection. It seems like that > > > could get really ugly. I don't know for sure, as I've been using > > > Spring property injection for some time and only rarely constructor > > > injection - they allowed me to be lazy in that regard :/ > > > > Right.. in this specific case a constructor collection and an add > > operation would be the best choice from Guice/Tapestry 5 perspective > > but then you'd really need to use either of those IoC containers to > > implement it properly. And there's no point re-working the internals > > now - this works and at least, like you said, it's consistent > > throughout. > > > > Kalle > > _________________________________________________________________ > Hotmail has tools for the New Busy. Search, chat and e-mail from your > inbox. > > http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1 >
