avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Carapetyan <p...@datafundamentals.com>
Subject Re: Separation of Interface from Implementation visuals
Date Sat, 06 Apr 2002 03:31:31 GMT
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:pete@datafundamentals.com]
> > 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:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message