shiro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bryan Turner <incomm...@hotmail.com>
Subject RE: r942498 - removing all convenience methods?
Date Wed, 12 May 2010 23:29:56 GMT

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.korhonen@gmail.com
> To: shiro-dev@incubator.apache.org
> 
> On Wed, May 12, 2010 at 2:43 PM, Les Hazlewood <lhazlewood@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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message