Leo: Reply to your comments and suggestions from below.
As relates the jar issue, since it didn't seem to be part of the Interface/Impl question except in passing, I thought that would best be saved for another graphic. Let me know if you feel strongly that it must be included here. Regarding your request for me to xdoc this, I have never done that before. Is it simply a matter of closing all my HTML tags? Or is there a site somewhere I should go to introduce myself to a specific methodology? Thanks, Pete Carapetyan Leo Simons wrote: > > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
