Not sure this is really a "technical" reason, but the GoF Design Patterns book 
recommends "favour aggregation over inheritance". I don't have it to hand but I think 
the reason might be that by extending a class, there is always scope to break the 
contract implemented by the superclass. By aggregation the caller is forced to 
acknowledge that it is not calling the superclass. Of course, this doesn't apply to 
interfaces as there is no implementation to override. The caller always has to trust 
the implementor to adhere to the interface contract.

Hope this helps
Keith


-----Original Message-----
From: Lutz Michael [mailto:[EMAIL PROTECTED]
Sent: 11 June 2003 15:51
To: '[EMAIL PROTECTED]'
Cc: Agassi Emin
Subject: seeking guidance - wrapping Log4j





I receive regular questions from internal customers asking why it is
recommended to wrap Log4j through aggregation as opposed to inheritance.

I am familiar with the ClassCastException issue found in
http://jakarta.apache.org/log4j/docs/TROUBLESHOOT.html#cce.
I have purchased the Log4j Full Manual, and will search for information in
this regard.  I've noted there is a section in the book covering wrapping
Log4j.

In addition, would someone please comment on the technical reasons
aggregation is recommended, as opposed to sub-classing?

Thanks for your time.

Mike

-------------------------------------------------------------------------------
This message and any included attachments are from Siemens Medical Solutions 
USA, Inc. and are intended only for the addressee(s).  
The information contained herein may include trade secrets or privileged or 
otherwise confidential information.  Unauthorized review, forwarding, printing, 
copying, distributing, or using such information is strictly prohibited and may 
be unlawful.  If you received this message in error, or have reason to believe 
you are not authorized to receive it, please promptly delete this message and 
notify the sender by e-mail with a copy to [EMAIL PROTECTED]  Thank you

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to