Peter, All points noted. Will implement.
-PH >Hi, > >Looks nicer. > >On Sun, 31 Mar 2002 02:17, Paul Hammant wrote: > >>Page http://jakarta.apache.org/avalon/framework/index.html >>------------------------------------------------------------- >> >>1) "Target Audience" >> >>Is now : This documentation is aimed towards developers who are >>interested in the design principles of Avalon, or wish to develop code >>that will be incorporated into Avalon >> >>Should be : This documentation is aimed towards developers who are >>interested in the design principles of Avalon, or wish to develop code >>that will be incorporated into Avalon, or reuse Avalon concepts in their >>own application. >> > >Okay - also delete the second paragraph in introduction as it is no longer >relevent. > >>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. >> > >I think we should just start discussing about separation of implementation >and the interface/contract. Dont worry about describing classloader/jar >issues just yet. > >The main reason I do it is because; > >1. it forces you to decouple different modules/components/objects >2. if specified correctly allows you to easily change the implementation of >the interface/contract in the future. >3. makes it possible for a user to read documentation about interface without >having the implementation details clutter up their perception > >if you are building objects with the aim of reuse then [2] is important but >most people don't build for reuse (and most XP advocates say you should just >plan to use not reuse) and thus [1] and [2] are more important. If you feel >like documenting that and expanding this then feel free to. > >Tackling the separation of ClassLoaders/jars is a related but different >issue. It could be documented but I think it may be best to tackle this >second and put it in a a different document. This is mainly because many >applications do not require that level of separation. > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
