Brett McLaughlin [[EMAIL PROTECTED]] wrote:
> > Yup, sure does. (I wondered about that additional layer of abstraction.)
> I'll
> > try to flesh out some code this weekend so we have more to go on.
>
> Yeah, and some of that is in projects I work on at work, and not yet
> committed to Turbine. (bad me...)
>
Okay, then I guess I'll hold off until you pull some of that together. Let me
know if you need any help.
> > Some implementation questions:
> > - Is a Vector fine for the params or should it be a dedicated class?
> > - Should TurbineServiceManager be a replacement for the current
> > TurbineServices? If so, I'll need to add execute() to Service and
> > potentially break NamingService.
>
> Ummm.... I would let the parameter into an execute() type call always be of
> type Object. That way we can define a generic service contract that doesn't
> have to be service-implementation dependent. Then the individual services
> have to check (using instanceof or something similar) if the object passed
> is is the approprtiate type, and throw an exception if not (again, the
> contract can define this, like IllegalArgumentsException).
>
Sounds good.
> I'll try and look into TurbineServiceManager vs. TurbineServices this
> weekend.... I am mixing my projects' at work's terminolgy with Turbine...
> but really, I tend to think TurbineServiceManager might be a better name, as
> it is more descriptive of what it does. What do you think?
>
Manager seems a little easier to delineate when you scanning code, so I guess
that's my preference. Although I'm not too picky!
--
Christopher Elkins
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
