avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pete Carapetyan <p...@datafundamentals.com>
Subject Re: designing for reuse (.xml)
Date Sat, 13 Apr 2002 00:52:01 GMT
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:   <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>

View raw message