avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Simons" <leosim...@apache.org>
Subject designing for reuse (.xml)
Date Fri, 12 Apr 2002 21:35:21 GMT
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>


Mime
View raw message