Bruce Snyder wrote:
AB>Unfortunately, the isA/hasA debate is something that can run and run
AB>and run, and since the initial code seed has gone with JMX then it
AB>seems very difficult to nudge that another way. But a more generic
AB>container framework (the likes of
AB>Avalon/Merlin/Hivemind/Eclipse-Plugin-Style) that /has/ a JMX interface
AB>would be a 'cleaner' approach from an OO perspective.
A very interesting point here, Alex.
In my experience with components, the distinction is more along the lines
of usesA/containsA.
Well designed components do one thing, and do it well. All other functions
are relegated to other components. Now with a component based design, we
have new distinctions to look at.
You still have the OOD ways of extending the system: extending classes/
implementing interfaces. You also have two new ways to refer to how one
component interacts with other components. Due to the nature of a component's
late binding (by design), the only choice for one component using other
components is to either _use_ one that is provided or _contain_ one inside
of it.
Using Cocoon as an example: if I have a DirectoryGenerator I can extend it
so that it reports image types and dimensions calling it an
ImageDirectoryGenerator. It IS a Generator (impementing the interface), and
it IS a DirectoryGenerator (extending the base class).
Additionally the code that checks a File reference to see if it is an image,
and what dimensions it has, that code can be made into a component. Advantages
and disadvantages of the approach are ignored for the time being. By allowing
the parent container to control that component would mean that the
ImageDirectoryGenerator needs to look up the component and use it. I.e. the
_uses_a_ approach. It can be argued that the only place in the entire system
that would use the component is encapsulated inside the ImageDirectoryGenerator,
so that would encapsulate the component. I.e. analogous to the "has a"
relationship in OOD.
The "Uses A" relationship is far more useful and common in component
architectures. If you ignore this relationship, then you are no longer using
components--you are just using structured OOD.
Late binding is a very powerful feature, which allows us to not only completely
replace one component for another, but also allows us to add in aspects such
as instrumentation, security, etc. all without altering the original component
code or the client code.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
