Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > design q: decorator pattern

Reply
Thread Tools

design q: decorator pattern

 
 
Chris Forone
Guest
Posts: n/a
 
      07-10-2008
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
 
Reply With Quote
 
 
 
 
Bernd Strieder
Guest
Posts: n/a
 
      07-10-2008
Hello,

Chris Forone wrote:

> 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

 
Reply With Quote
 
 
 
 
Chris Forone
Guest
Posts: n/a
 
      07-10-2008
Bernd Strieder schrieb:
> Hello,
>
> Chris Forone wrote:
>
>> 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
>


in gof-book there is an example:

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

Border/ScrollDecorator are dyn. allocated...
 
Reply With Quote
 
Michael DOUBEZ
Guest
Posts: n/a
 
      07-10-2008
Chris Forone a écrit :
> Bernd Strieder schrieb:
>>> 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++?

> 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);
}
};

--
Michael
 
Reply With Quote
 
Chris Forone
Guest
Posts: n/a
 
      07-10-2008
Michael DOUBEZ schrieb:
> Chris Forone a écrit :
>> Bernd Strieder schrieb:
>>>> 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++?

>> 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);
> }
> };
>


drawbacks:
- deco-objs in class foo, although i poss. dont need them
- ctor for every combination of deco-objs
 
Reply With Quote
 
Chris Forone
Guest
Posts: n/a
 
      07-10-2008
Bernd Strieder schrieb:
> Hello,
>
> Chris Forone wrote:
>
>> 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
>


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
 
Reply With Quote
 
Michael DOUBEZ
Guest
Posts: n/a
 
      07-10-2008
Chris Forone a écrit :
> Michael DOUBEZ schrieb:
>> Chris Forone a écrit :
>>> Bernd Strieder schrieb:
>>>>> is there a possibility to implement the decorator-pattern without
>>>>> new/delete (nor smartpt)?

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


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.

--
Michael
 
Reply With Quote
 
Bernd Strieder
Guest
Posts: n/a
 
      07-10-2008
Hello,

Chris Forone wrote:

> Bernd Strieder schrieb:
>> Chris Forone wrote:
>>
>>> 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++?
>>

> 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

 
Reply With Quote
 
Daniel T.
Guest
Posts: n/a
 
      07-10-2008
On Jul 10, 6:07 am, Chris Forone <(E-Mail Removed)> wrote:

> 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.
 
Reply With Quote
 
James Kanze
Guest
Posts: n/a
 
      07-11-2008
On Jul 10, 12:39 pm, Chris Forone <(E-Mail Removed)> wrote:
> Bernd Strieder schrieb:


> > Chris Forone wrote:


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


> 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 (GABI Software) email:(E-Mail Removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C++ and design Pattern (Composite design Pattern ) Pallav singh C++ 1 01-22-2012 10:48 PM
C++ and design Pattern (Composite design Pattern ) Pallav singh C++ 0 01-22-2012 10:26 PM
C++ and design Pattern (Composite design Pattern ) Pallav singh C++ 0 01-22-2012 10:25 PM
May I have a example of design pattern of "composite", I still feel fuzzy after reading book of Addison-Wesley's"design pattern " jones9413@yahoo.com C++ 1 08-31-2007 04:09 AM
explanations about the Decorator design pattern Jean Lutrin Java 8 11-18-2004 05:40 PM



Advertisments