Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 71344 invoked from network); 13 Apr 2002 00:50:23 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 13 Apr 2002 00:50:23 -0000 Received: (qmail 2980 invoked by uid 97); 13 Apr 2002 00:50:30 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 2964 invoked by uid 97); 13 Apr 2002 00:50:29 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 2953 invoked from network); 13 Apr 2002 00:50:29 -0000 Message-ID: <3CB78131.DF6FDE57@datafundamentals.com> Date: Fri, 12 Apr 2002 19:52:01 -0500 From: Pete Carapetyan X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: designing for reuse (.xml) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N This was discussed in another forum some weeks ago, and the same conclusion was reached as what Leo proposes below. Since it disturbed me at the time to go against what Mr. Foote had written, I went back and studied Mr Foote's analysis. This is what had led me down the abstract path/ If memory serves me correct about the spatterings that I read, it led me to believe that since it was written in the mid 80s, perhaps interface as java uses it is what he had in mind at the time, but by the use of the word abstract, and perhaps abstract was intended to mean as not concrete instead of abstract like java uses it. Does that sound like a logical conclusion? Leo Simons wrote: > > from our framework docs: > > "The Top of the Class Heirarchy Should be Abstract > > In many cases it is beneficial to provide an abstract base class to extend > for your specializations. The majority of the functionality and behavior is > well defined. This makes it easier to decipher what the intents of the > interface designer were. " > > While I can understand the reasoning, I cannot agree > with the rule. In many cases, abstract base classes > lead to separating code that should logically be > together into multiple files. When there is one > abstract class in the hierarchy, all is well, but when > you have two, three or twenty, it is a nightmare. > > Someone recently dumped some code on my desk where > there was a lot of abstract classes being extended. > It is a nightmare to figure out what happens, when it > happens, and where it happens. So while there is reuse, > it comes at too high a cost. > > One of the nice things about avalon is that it is based > more on components instead of inheritance. Unless proven > otherwise in a particular case, I favor composition over > inheritance. IOW, mr. Foote and mr. Johnson are, in my > honest but stubborn opinion, not quite right. > > Quote could instead be: > > "The Top of the Class Heirarchy _Could_ be Abstract > > In _some_ cases it _can_ be beneficial to provide an abstract base class > (...) > If this is used too much, it leads to The Big Ball Of Mud design pattern." > > which seems rather stupid to include. > > thoughts? > > cheers, > > - Leo > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: