Re: [RT:A5] What are the _real_ concern areas?

Peter Donald <[email protected]>
Newsgroups gmane.comp.jakarta.avalon.apps.devel,gmane.comp.jakarta.avalon.devel
Message-ID <[email protected]>
On Fri, 20 Dec 2002 17:09, Adam Murdoch wrote:
> > Some component styles don't implement Contextualizable or
> > Serviceable/Composable or Configurable/Parameterizable or whatever.
>
> But this isn't a benefit.  It's flexibility for it's own sake.

If it was flexability for it's own sake then people would not use it.

> So what's missing?  What can we add that demonstrates that the current
> framework is really more flexible and scalable than the modified framework?

Add in 5 more different types of resources (say Instrumentation, Persistence, 
Security, Transaction or whatever). Currently you can just insert extra 
lifecycle stages into component style and these resources get supplied. 

If you need to customize the way things are provided. Ie a while ago Myrmidon 
supplied a custom Configuration object that supported getChildren() method. 
Plexus supports ServiceBroker rather than ServiceManager, Phoenix has 
BlockContext, Cocoon uses Instrumentable. I know other of other containers 
that have alternative needs.

In a monolithic framework this becomes difficult/impossible to do cleanly. You 
end up doing things like

((SpiceServiceContext)context).getManager()
(ServiceBroker)context.getServiceManager()
(BlockContext)context.getContext()

and you end up requiring super classes just to deal with introduced 
complexity.

I am not a great fan of frameworks that require tools or super class 
hierarchies just to bring them back to sane complexity levels.

> > > Whatever you happen to call this antipattern, taking a single real
> > > concern and dividing it into several artifical concerns causes
> > > problems.
> >
> > I don't believe anyone has shown that they are "artifical concerns".
>
> No.  But that's what we're trying to figure out.  And with lifecycle
> methods, it's a case of "useless until proven useful".  So far, noone has
> shown that 5 (or 6) resource delivery lifecycle methods are more useful
> than one.

Fine grain is useful when you want to do fine grain stuff. In the end it is 
basically personal preference and scope of application. ie What color is your 
bike shed?

-- 
Cheers,

Peter Donald
"All my life I wanted to be someone; I guess I should have been more 
specific."
-- Jane Wagner
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.