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
