-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: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
