Pete, >>2) "Theoretical Aspects of Component Development" >> >>I'd like to add a new pattern that we already informally treat >>reverently. It is "Interface/Impl seperation". People understand it but >>do not really apply it, of it is mucked up. Catalina, for example, is >>supposed to be interface/impl separated but is (or was last time I was >>active in their mail list) not. The other thing that wven we are >>historically a bit guilty of is the separation in terms of jars. We >>desire this because we want to hide implementation. Following of from >>Peter's K/CAPI/HC trinity of classloaders, where Hosted comps (HC) only >>see the Client API (CAPI), the Kernel (K) may have chosen to hide the >>impl of the CAPI in a different clas loader, not just by dyanmic proxy. >>The K/CAPI/HC trinity will be repeated many times over in the most >>complex cases (Phoenix hosting JAMES, FtpServer, Jesktop, EOB). It would >>be good if we could really start promoting this. At least I am getting >>sick of explaining it to the people I meet on the net when they have >>something that is almost a good candidate for an example for EOB. One >>case wherewe have it wrong is I think cornerstone.jar, it contains >>interface and impl and will probably be left as is for historical reasons. >> > >We are already trying to address this in our own little Avalon framework, and I >would like to repeat it below to make sure that I understand properly, and to >make sure that I am understanding what you are saying. > >Basically, we decided to call it, at least for the moment, the InformingAPI >pattern. > >What that says is that XxxComponent may be BlahComponent or FooComponent, but >that regardless of where it came from, what it is intended to do is implement >the JXXX Api. The agreement then, is to use an InformingAPI to define the >interface, and then BlahComponent, FooComponent and BarComponent may then >implement this interface in their own black box kind of way. > >What this does for us is make sure that the first guy to implement a component >works to a common API, such as JAAS, JCA, or JBLAH, instead of just doing his >own thing. That way the next guy works to the JBLAH interface when he writes his >plubbable component, not to the interface set by the JBlahComponent, which has >every right to be funky, without the InformingAPI pattern. Keeps the idea of >pluggability possible in practice, rather than just as an abstract idea that >falls apart when the second implementation doesn't work to the same interfaces >that the first guy uses. > >Does that make sense? ...or did I go off into different waters? > More or less the same thing. The first person to code the the thing deliberately creates interfaces thus making an API. Wiley's Patterns for Java book refers to it as 'Interface' and cites Grand98 as the origin. It is a dodgy thing to include in a pattern book as Java has it as a core concept. Having said that people think iyt is mostly for things they use and not things they make. It is worth pushing..
You have not talked about an equally important test of your seperation. Zip the interface into one jar, the impl into another and a test into a third. Mount the three in different classloaders with only the interfaces visible to both the other two. I.e. it is no good separating if you distribute both in one Jar. Lastly, when you say "our own little Avalon framework" what do you mean ? - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
