Simons, ( <<< Don't send messages to "this" )
by itself, that rule is nonsensical. But a following
point clarifies:
"Send Messages to Components instead of to This
The point of this point is that you want to build your
framework based on Components, and not inheritance. Avalon
takes this point to heart. In order to illustrate, I will
give two examples of the same thing. The scenario is that
we have a data structure that we want to output to an
arbitrary format."
Abstract Base Classes (ABC) are useful, when some operations
defined in a interface can easily be expressed in other,
so I have nothing against them.
But of course, wrongly used you have to hunt up and down
the hierarchy to figure out what is really happening.
I guess, like most religious wars over coding, it boils
down to:
"Used correctly, X is a good thing."
I say kill that quote (ABC). Avalon is a Component
framework, something which is repeatedly stated in
the page, so a quote about how to define inheritance
hierarchies - esp. one that you have to qualify
endlessly with "where appropriate" - is a bit out
of place.
(Also, Foote and Johnson state:
"Inheritance vs. decomposition
Since inheritance is so powerful, it is often overused.
Frequently a class is made a subclass of another when it
should have had an instance variable of that class as a
component. For example, some object-oriented user-interface
systems make windows be a subclass of Rectangle, since
they are rectangular in shape. However, it makes more
sense to make the rectangle be an instance variable of
the window. (...)
Behavior can be easier to reuse as a component than by
inheriting it. (...) The first is that a parser inherits
the behavior of the lexical analyzer instead of having
it as a component. This caused problems when we wanted
to place a filter between the lexical analyzer and the
parser without changing the standard compiler.")
/LS
> -----Original Message-----
> From: Leo Simons [mailto:[EMAIL PROTECTED]]
> Sent: den 12 april 2002 23:35
> To: Avalon Development
> Subject: designing for reuse (.xml)
>
>
> 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
