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: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
-- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@;osm.net http://www.osm.net -- To unsubscribe, e-mail: <mailto:avalon-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:avalon-dev-help@;jakarta.apache.org>
