design q: decorator pattern

[Chris Forone]

hello group,

is there a possibility to implement the decorator-pattern without
new/delete (nor smartpt)?

if not, how to ensure correct deletion of the objects?

thanks & hand, chris

 

[Bernd Strieder]

Hello,

is there a possibility to implement the decorator-pattern without
new/delete (nor smartpt)?

Why should new/delete be mandatory for the decorator pattern in C++?

Bernd Strieder

 

[Chris Forone]

Hello,



Why should new/delete be mandatory for the decorator pattern in C++?

Bernd Strieder

in gof-book there is an example:

window->SetContents(
new BorderDecorator(
new ScrollDecorator(textView)
)
);

Border/ScrollDecorator are dyn. allocated...

 

[Michael DOUBEZ]

Chris Forone a écrit :

in gof-book there is an example:

window->SetContents(
new BorderDecorator(
new ScrollDecorator(textView)
)
);

Border/ScrollDecorator are dyn. allocated...

This is not necessary

class foo
{
TextView textView;
ScrollDecorator scroll;
BorderDecorator border;
WindowApp window;

public:
foo():scroll(&textView),border(&scroll)
{
window.SetContents(&border);
}
};

 

[Chris Forone]

Chris Forone a écrit :

This is not necessary

class foo
{
TextView textView;
ScrollDecorator scroll;
BorderDecorator border;
WindowApp window;

public:
foo():scroll(&textView),border(&scroll)
{
window.SetContents(&border);
}
};

drawbacks:
- deco-objs in class foo, although i poss. dont need them
- ctor for every combination of deco-objs

 

[Chris Forone]

Hello,



Why should new/delete be mandatory for the decorator pattern in C++?

Bernd Strieder

possibly some design-ideas?

i have an abstract class visual, class module and class decorator derive
from visual. module can draw himself, some decorators apply color,
texture, normals to the module. i think the deco-patt. is a good
approach poss. with smartptrs to ensure obj deletion...

cheers, chris

 

[Michael DOUBEZ]

Chris Forone a écrit :

drawbacks:
- deco-objs in class foo, although i poss. dont need them
- ctor for every combination of deco-objs

So it is not related to the decorator pattern.
I assume your issue is how to delete the objects (when they are not
disposed of by the decorator) and not keep a reference to them.

IMO, your safest bet is garbage collection.

 

[Bernd Strieder]

Hello,

possibly some design-ideas?

There is too much open to reach an answer. And it starts to become
off-topic.

My first idea would be inheriting module in decorator and overriding the
things I want to change. But why not applying that color, texture,
normals on the module instance manually. The decoration makes only
sense if it happens often, and the decorated object has its own reasons
to exist.

Since this is on GUI code, many GUI frameworks have some facilities for
object destruction of the kind destruct and deallocate the window and
everything within. Better you try first to adjust to the usual ways of
your framework before trying something new.

What I really don't like about the way you have applied the decorator
pattern is, that there are 3 instances of subclasses of visual
involved, where only one should be, one visual decorated twice. In GUI
frameworks a base class like visual often has lots of state, which
probably needs to be copied for every level of applying decorator. That
seems pretty odd.

If your framework has been designed with all that in mind, e.g. the
decorators really are only thin wrappers, then it might be possible to
establish some owner relation between the decorators/decorated objects
and make their root responsible for the others (probably the outermost
decorator) and attach the outermost decorator to its embedding object
in a way that destruction can be done. If smart pointers are used then
only c'tors of the classes are involved

Bernd Strieder

 

[Daniel T.]

is there a possibility to implement the decorator-pattern without
new/delete (nor smartpt)?

Yes, as Michael Doubez has shown, but then the Decorator is sharing
its component with something else, which isn't optimum.

if not, how to ensure correct deletion of the objects?

By simply using a smart pointer, or putting deletes in the appropriate
places. Why would you want to avoid using new/delete or smart
pointers?

The point of the Decorator pattern is that the Decorator has sole use
of the concrete Component it contains so it can control what the
component receives from the world at large. To ensure this, the
Decorator must have ownership of the component it contains.

 

[James Kanze]

Bernd Strieder schrieb:

in gof-book there is an example:

window->SetContents(
new BorderDecorator(
new ScrollDecorator(textView)
)
);

Border/ScrollDecorator are dyn. allocated...

In this particular case, they are both dynamically allocated;
the window is the only object which has a pointer to the
BorderDecorator, and the BorderDecorator is the only object
which has a pointer to the ScrollDecorator. Presumably, in this
particular case, they have established a convention that the
relevant classes are responsible for the delete (or they are
using the Boehm collector, but given when the book was written,
I doubt it).

In this particular case. There's no reason why it would always
be the case. In other cases, the objects involved may have
automatic lifetime, or be managed elsewhere. In many of my
decorators, I've found it useful to add a second parameter, a
bool deleteWhenFinished. If you pass it true, the decorator
does delete the decorated object in the destructor, if you pass
it false (which is the default), it doesn't. Garbage collection
would help here most of the time, but at least in one case, the
decorated objects use limited resources and require
deterministic destruction, so even with garbage collection, I'd
keep the flag and the (optional) delete.

 

[James Kanze]

Yes, as Michael Doubez has shown, but then the Decorator is
sharing its component with something else, which isn't
optimum.

That wasn't the case in Michael's example. There was a higher
level component which set up the pattern, but that's always the
case.

By simply using a smart pointer, or putting deletes in the
appropriate places. Why would you want to avoid using
new/delete or smart pointers?

Because it's not generally necessary? Because in some cases,
someone else is already managing the object lifetime? (One of
the frequent uses of the decorator pattern in my code is a
filtering streambuf. And if the decorated streambuf comes from
std::cin, I'd better not delete it.)

The point of the Decorator pattern is that the Decorator has
sole use of the concrete Component it contains so it can
control what the component receives from the world at large.

Sole use for a certain period of time, maybe (although even this
isn't really guaranteed---or even usual).

To ensure this, the Decorator must have ownership of the
component it contains.

I don't know where you get this from. There are cases where the
decorator must be the only object accessing the decorated, for
the period of time the decorator exists, but there probably the
exceptions.