very nice!
I'm not good at visual explanations, but you did make me look
at an old concept (for me, it's in the "well, doh!" category
by now) in a new way.
Something that you didn't address completely is the
packaging (there's jars in the first graph, not in the later
ones).
We would of course have
1 jbar-interface.jar jbar-interface-myExtension.jar
| |
| implements | implements
| |
2 jbar-myImplementation.jar jbar-myImplementation-myExtension.jar
| |
| contains | contains
| |
3 jbar-myimplementation-complete.jar
where either the second or third layer is optional. And with regards to
Jimmy,
he would then:
1 jbar-interface.jar jbar-interface-myExtension.jar
jbar-interface-jimmyExtension.jar
| |
|
| implements | implements
| implements
| |
|
2 jbar-myImplementation.jar jbar-myImplementation-myExtension.jar
jbar-jimmyImplementation-jimmyExtension.jar
| |
|
| contains | contains
|
| |
|
3 jbar-myimplementation-complete.jar
|
|
|
| dependency
/-----------------------------------------/
| |
4 jbar-jimmyImplementation-complete.jar
note on the relationships: implements implies dependency.
So an implementation-xxx.jar depends on an interface-xxx.jar.
It would be really cool if you could make some of these
changes and create an xml (xdoc) document out of all this...
cheers,
- Leo Simons, who finally had A Good Night Of Sleep(tm) again last night
> -----Oorspronkelijk bericht-----
> Van: Pete Carapetyan [mailto:[EMAIL PROTECTED]]
> Verzonden: Friday, April 05, 2002 6:58 PM
> Aan: Avalon Developers List
> Onderwerp: Separation of Interface from Implementation visuals
>
>
> Separation of Interface/Implementation
>
> At the risk of exposing myself as a person with a small mind, I
> am submitting a draft visual for approval of the Separation of
> Implementation from Interface. Couldn't seem to work it out,
> without the visuals.
>
> The problem for me is simple. Inversion of Control and Separation
> of Concerns really help, but my interest is in true pluggability.
> True pluggability falls apart like a big dog, right when the
> first guy that writes a component defines the interface just by
> being nice enough to contribute an implementation.
>
> He didn't intend to mess up the interface, but if the interface
> is not defined by some standard API rather than his custom
> implementation, no amount of good intentions makes it possible
> for the next guy to follow behind. So that is the problem.
>
> If the problem is simple, the solution did not seem so simple.
> This is because of the many to many relationship between APIs and
> interfaces, and the one to many relationship between an
> implementation and interfaces. A strictly hierarchical approach
> doesn't work in all cases, so I had to map it out visually to
> figure out if it was even possible to come up with a methodology
> that would work for everything.
>
> What follows is a first draft. It is intended that smarter
> persons than myself will find many logic errors, and I will
> correct the visuals accordingly. When ready, or at any time, the
> Avalon committers may submit at their discretion, to add to what
> is already written on Interface/Impl.
>
> http://couldbe.net/InterfaceImpl/
>
> Thanks for your help in sorting this out.
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
