proxyuser wrote:
"Barry Kelly" <ba***********@ gmail.comwrote in message
news:8b******** *************** *********@4ax.c om...
Well, if we can't change the Component class, then how can the
Component class implement a common interface?
There seems to be some information missing from your question. What is
this common interface you speak of? What is the set to whose members it
is common?
It's whatever is the abstract class. In GoF (fourth printing, 1995), it's
VisualComponent on p. 176, or Component on p. 177.
I don't have that book.
The decorator pattern is very roughly interface inheritance combined
with aggregated implementation. Since you can't change the underlying
class, you subclass its main interface (e.g. Component)...
Yes, but this doesn't seem quite right. Component is not the preexisting
class.
You see, when you mentioned "Component" in a .NET forum, I assumed you
meant System.Componen tModel.Componen t.
And I do not mean "the preexisting class" by Component; I meant the base
class, the one that defines the interface through which the class you
are trying to decorate interacts with the rest of the system.
In the example on p. 176, the preexisting class is TextView, and
that is the class we want to decorate. So they add an abstract class above
it, called VisualComponent . This requires that the TextView class is
changed to inherit from VisualComponent . On p. 182 they say "TextView is a
VisualComponent ", which is what makes it interchangeable .
And yet on p. 177, they say to use Decorator when "a class definition maybe
be hidden or otherwise unavailable for subclassing." If TextView, for
example, were hidden or unavailable, then how can it be changed to inherit
from VisualComponent as the design requres?
I suspect that you are misreading the authors' intentions; it is not
that TextView is *changed* to inherit from VisualComponent , but rather
that TextView, for the sake of the example, is *asserted* to inherit
from VisualComponent . It seems to me that it makes little sense to
magically introduce a VisualComponent if the rest of the whole UI system
doesn't know what to do with a VisualComponent .
This page here seems to conform to my expectations of what the authors
intend:
http://www.exciton.cs.rice.edu/JavaR...ires/pat4d.htm
In any case, to make it concrete, and bring the discussion to something
that everyone can follow, assume you have a TextView deriving directly
or indirectly from Control - i.e. System.Windows. Forms.Control.
Now, a typical example of a decorator is a GUI widget that adds
scrollbars. If you want to add scrollbars to this TextView (the one
whose existence I've asserted just above) using the decorator pattern
(i.e. pretending we aren't running on Windows and that Control doesn't
already encapsulate a window handle etc.), you would need to write a
separate class which descends from Control, and contains a TextView
instance. It would handle drawing the scrollbars and keeping track of
their state, and when it needed to draw its client area, it would hand
off the appropriate clipped section for the TextView to draw on; and
similarly for events, etc. - it would pass them on after checking if
they are only applicable to the scrollbars. It would also probably e.g.
transform mouse events as appropriate for the visible client area.
The whole point of the decorator pattern outlined above is that you
don't have to rely on TextView not being sealed, or on TextView having
source code you can modify. Because TextView is just an implementation
of Control, you can write your own Control - i.e. conform to the
interface - and only delegate to the inner instance when desired.
And because this instance is held internally at runtime, you can make
decisions about reimplementatio n versus delegation at runtime, as well
as composing multiple layers of decorators as needed. Basically, the
decorator pattern can be more flexible than direct inheritance, for the
same reason that aggregation is more flexible than inheritance.
-- Barry
--
http://barrkel.blogspot.com/ 
