-Andy
Stephen McConnell wrote:
Andrew C. Oliver wrote:
> Okay so you've hooked me.
:-)
> Show me a set of code that you regard as WELL designed and
> UNDERSTANDABLE (which means maintainable over time as well). My
> biggest problem with the approach you suggest is the only examples I
> have of code that was done in that way I seriously seriously seriously
> dislike. I also have a gripe against excessive "is a" relationships
> but putting that aside. Point me to something that was done well that
> uses the framework in the manner you suggest.
All of the containers in Avalon (Merlin, Fortress, Phoenix) have been
built the patterns I've described. But I don't think that's a good
solution in terms of pointing you to something because it will be really
easy to get mixed up about things because you will be looking at
component based systems proving component management.
There are examples of Phoneix components that follow this pattern in the
cornerstone package, and the james is an example of a system based on
the composition of components - but you should probably post an email to
the Phoenix list to get suggestions on which of these components you
should be looking at.
I have a lot of stuff I'm working on that's internal that meets your
criteria. But to get to this position I've had to build the container
API to provide the proper seperation of container-side verus component
concerns. I'm not saying there isn't well designed and understandable
systems out there based on Avalon, but I do think that these examples
will be of limited complexity. Without these sort of container-side
service abstractions the code in a complex system starts to get
complicated with component management artifacts - in other words -
things get cluttered and unnecessarily complicated. Based on the work
with excalibur/assembly, meta, container, configuration, I've managed to
substantially simplify my code base and get a big application under
control and readily understandable.
Cheers, Steve.
>
>
> -andy
>
> Stephen McConnell wrote:
>
>>
>>
>> Andrew C. Oliver wrote:
>>
>> > Some time ago someone sent me some ideas on how to use avalon in a
>> > service based strategy such that it would be more containment based
>> > than inheritance based (and bare will me that I regard interface
>> > implementation as inheritance because its "is a" not "has a").
>> > Basically, I don't want everything to implement 10 different
>> > interfaces. i'd rather null operations... So I lost the message
>> > (long story short, fired, lost laptop, rehired by same company in
>> > different group, new laptop...stupid mozilla default settings had
>> > deleted mail of my server against my will).. But I'm ready to do it
>> > now ;-)
>> >
>> > What I basically want is:
>> >
>> > public class AbstractService implements x, y, z, ... {
>> >
>> > ??
>> >
>> > public SomeType someLifecycleMethodImNotUsing() {
>> > return null;
>> > }
>> >
>> > }
>> >
>> > What are the x, y, and zs that I should most likely use?
>>
>>
>> Probably:
>>
>> LogEnabled,
>> Initializable,
>> Disposable
>>
>> But if you wanted to do the grand abstract approach, you could do
>> something like:
>>
>> LogEnabled,
>> Serviceable,
>> Contextualizable,
>> Configurable,
>> Initializable,
>> Startable,
>> Disposable
>>
>> But I also think it is bad approach. I'll explain why.
>> Creation of abstract class is something that makes sence when the
>> underlying functionality is "rich". That isn't the case with any of the
>> above - as you will have seen from Leo's email you just end up with an
>> object holding a bunch of state members. What's missing is the
>> relationship between that object and its container. All of the above
>> interface provide the formal points of inteaction between a container
>> and a component.
>>
>> LogEnabled
>>
>> assignment of the logging channel that
>> the component will use (component does
>> not see any particular logging implemetation)
>>
>> Serviceable
>>
>> assignment of the services that the compoent
>> needs to function to do its job (component
>> should never need to go hunting for the service
>> it neeeds) - service that the component needs
>> would typically be declared as depedencies in
>> a meta declaration and the container will take
>> care of service provisioning
>>
>> Contextualizable
>>
>> supply of the runtime context - again, the
>> context information that the component needs
>> (key + type) can be declared in meta info so
>> a container can make sure the component gets
>> all of the context information it needs
>>
>> Configurable
>>
>> supply of the component configuration by the
>> to the component.
>>
>> Initialiable
>>
>> request from the container to the component
>> to initialize itself, typically the
>> component implemetation will validate internal
>> state at this point
>>
>> Startable
>>
>> only applicable in the case of a component that
>> needss to start up its own thread of execution
>> (i.e. a component acting as a server for example)
>> - called by the container to instruct the component
>> to start or stop doing its stuff
>>
>> Disposable
>>
>> Used by a container to tell the compoent to clean
>> up state
>>
>> Problem with the "AbstractService" approach is the abstract work should
>> be in the container, not in the component. It the container that has to
>> take care of doing all of the leg work to make sure the component gets
>> everything it needs. It does this based on a combination of (a)
>> lifecycle interfaces as described above, and (b) supplimentary meta
>> information describing the component deployment criteria.
>>
>> By pushing all of the overhead onto the container, you end up with much
>> better code in you component implemetation, and much less code.
>>
>>
>> > And what else do I need?
>>
>>
>>
>> 1. a container
>> 2. a component / service model (design)
>>
>> >
>> > In short my application is a reporting service which lets me pull from
>> > a number of data sources, execute various transformations and get out
>> > a report via various delivery methods. So I have DataProviderService
>> > which has for instance a JDBCService which can process QueryDefs to
>> > get stuff from a database (I don't ermember the names I have thus
>> > far). So far I've stubbed most things out and I'm fairly happy with
>> > it, but I'd rather not re-invent the wheel, hence my interest in using
>> > Avalon in place of the little "Service" and "ServiceManager" classes I
>> > used as placeholders..
>> >
>> > Thoughts?
>>
>>
>>
>> Doing cause-grained component oriented development is an approach that
>> lets you break apart systems more formally, and from that, the overall
>> system (a set of assembled components) becomes much, much simpler to
>> build. In fact, combining the Avalon component model with meta
>> information enables the automation of system assembly and deployment.
>>
>> Cheers, Steve.
>>
>> >
>> > thanks,
>> >
>> > Andy
>> >
>> >
>> >
>> >
>> > --
>> > To unsubscribe, e-mail:
>> >
>> > For additional commands, e-mail:
>> >
>> >
>> >
>> >
>>
>
>
>
>
> --
> To unsubscribe, e-mail:
>
> For additional commands, e-mail:
>
>
>
>
-- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
