design q: decorator pattern

Discussion in 'C++' started by Chris Forone, Jul 10, 2008.

  1. Chris Forone

    Chris Forone Guest

    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
     
    Chris Forone, Jul 10, 2008
    #1
    1. Advertising

  2. 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
     
    Bernd Strieder, Jul 10, 2008
    #2
    1. Advertising

  3. Chris Forone

    Chris Forone Guest

    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...
     
    Chris Forone, Jul 10, 2008
    #3
  4. 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
     
    Michael DOUBEZ, Jul 10, 2008
    #4
  5. Chris Forone

    Chris Forone Guest

    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
     
    Chris Forone, Jul 10, 2008
    #5
  6. Chris Forone

    Chris Forone Guest

    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
     
    Chris Forone, Jul 10, 2008
    #6
  7. 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
     
    Michael DOUBEZ, Jul 10, 2008
    #7
  8. 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
     
    Bernd Strieder, Jul 10, 2008
    #8
  9. Chris Forone

    Daniel T. Guest

    On Jul 10, 6:07 am, Chris Forone <> 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.
     
    Daniel T., Jul 10, 2008
    #9
  10. Chris Forone

    James Kanze Guest

    On Jul 10, 12:39 pm, 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++?


    > 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:
    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
     
    James Kanze, Jul 11, 2008
    #10
  11. Chris Forone

    James Kanze Guest

    On Jul 10, 2:51 pm, "Daniel T." <> wrote:
    > On Jul 10, 6:07 am, Chris Forone <> 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.


    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.

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


    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.

    --
    James Kanze (GABI Software) email:
    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
     
    James Kanze, Jul 11, 2008
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jean Lutrin
    Replies:
    8
    Views:
    673
    Chris Uppal
    Nov 18, 2004
  2. Gregory
    Replies:
    3
    Views:
    363
    Gregory
    Dec 15, 2006
  3. Pallav singh
    Replies:
    0
    Views:
    373
    Pallav singh
    Jan 22, 2012
  4. Pallav singh
    Replies:
    0
    Views:
    410
    Pallav singh
    Jan 22, 2012
  5. Pallav singh
    Replies:
    1
    Views:
    460
    Peter Remmers
    Jan 22, 2012
Loading...

Share This Page