Decorator pattern in C#

[proxyuser]

The context of this question is actually from the book "C# 3.0 Design
Patterns" (Bishop).

She makes the point that one of the reasons you'd use Decorator is if
you can't change the original component class. On p. 17, she explains
a code example: "...this code deviates from the [original] pattern
laid out...there is no IComponent interface. This is perfectly
acceptable; the decorators can inherit directly from the component and
maintain an object of that class as well. ...However, this code does
realy on the original Component [declaring a particular method as
virtual.] If this is not the case, and we cannot go in and change the
Component class, an interface is necessary."

Well, if we can't change the Component class, then how can the
Component class implement a common interface? Conceptually, this is
the same thing as inheriting in this context. If you don't have
access to changing the class, you can't do it. What am I missing?

 

[Barry Kelly]

The context of this question is actually from the book "C# 3.0 Design
Patterns" (Bishop).

She makes the point that one of the reasons you'd use Decorator is if
you can't change the original component class. On p. 17, she explains
a code example: "...this code deviates from the [original] pattern
laid out...there is no IComponent interface. This is perfectly
acceptable; the decorators can inherit directly from the component and
maintain an object of that class as well. ...However, this code does
realy on the original Component [declaring a particular method as
virtual.] If this is not the case, and we cannot go in and change the
Component class, an interface is necessary."

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?

Conceptually, this is
the same thing as inheriting in this context. If you don't have
access to changing the class, you can't do it. What am I missing?

This may help:

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), store an
instance of the class as a private member (this is the aggregation bit),
and (1) delegate all operations that make sense to the wrapped instance,
and (2) reimplement all operations that you wanted to change, but
couldn't access in the wrapped class.

-- Barry

 

[proxyuser]

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.

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. 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?

 

[Barry Kelly]

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.

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.ComponentModel.Component.

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/JavaResources/DesignPatterns/book/hires/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 reimplementation 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

 

[raylopez99]

I have Bishop's book, which is supposedly a remake of the Gang of
Four's book on the same subject, but tailored to C#. One criticism of
Bishop on Amazon.com is that her code sometimes doesn't work and is
too conceptual (which would defeat the purpose of the book, since you
can just buy the Gang of Four's book if C# is not your target).

Perhaps this example is one of those "broken code" instances people
have complained about.

That said, I have both Bishop and the Go4's books.

RL