Talk:Decorator pattern

My goodness. If I don't get to NPOVing/encyclopedicafying the "taco" example, could someone, please? Dysprosia 10:31, 4 Nov 2003 (UTC)

The latest PNA cycle improved a lot, but there's still a big gap between here and goodness ("objects can have attributes that change something about them" sounds like something from a philosophy article). Let me work it over a bit... JRM

OK, I've revamped it, hopefully clarifying it (and removing the absurd "taco" example altogether). I've also removed links to bean pattern (much too specific reference to Enterprise Java Beans) and self joining data (I've never even heard of this and I doesn't Google in any relevant way—if this is not just another fifteen-minutes buzzword and someone else has, please do write an article about it and (if it's related) reinstate the link).

I'm still not perfectly happy with what I've written (it's still not accessible enough to the Ignorant Outside World), but this is simply because I'm not a writer (and don't have access to Design Patterns at present). You there! Improve it! I don't know where you're from, but here on Wikipedia, we collaborate! :-) JRM 14:15, 2004 Nov 16 (UTC)

Ech, I just saw proxy pattern. We have a long way ahead of us. Anyone feel like a new WikiProject? :-) JRM 14:15, 2004 Nov 16 (UTC)

OK, I've added the section headings suggested by the Gang of Four on the Design pattern (computer science) page, and rearranged the existing content under these headings. However, we still need additional content. AmunRa84, 14:07, 2005 Jan 9 (UTC)

The layout looks fine so I'm removing the "wikify" tag. If the article still neads a lot of work, we can put "cleanup" instead? Jeeves 02:26, 9 Jun 2005 (UTC)

UML diagram

This page lacks the UML diagram. I would add it but I don't know if I can copy it from another site, and I don't have the time to do it myself and get a printscreen from it

Done ACiD2

If the Decorator implements the Component, shouldn't "doStuff()" be called "operation()"? It does so in the GoF book. MatthiasO

the UML diagram is wrong, as the method names are not consistent:

Component:Operation
ConcreteComponent:Operation
Decorator:DoSomething
ConcreteDecoratorA/B:DoStuff

all these methods should have the same name !!!! Malo

Decorator:DoSomething seems alright, as it doesn't implement "+Operation()". Implementation of Operation() is supposed to happen in the ConcreteDecorator. The DoStuff() seems indeed wrong, and that diagram doesn't make sense to me. Better look at the window-example, or the c++ example.

I don't have the software installed to repaint it, but I remove the image now, as it does more damage than merit.

Phresnel (talk) 09:31, 9 February 2009 (UTC)[reply]

Please next time have the courtesy to try fix the image, instead of just deleting it from the wiki. It's one thing to remove it from the article page if it's wrong, but to mark it for deletion because of a few text errors inside it? That's depriving everyone of that image. Wikipedia:Graphic Lab does image alterations, especially vector images, which I am a part of. I have no intention of re-uploading this image, so enjoy that. Too many of my images contributions to this wiki have been deleted for SILLY reasons. Have a nice day.XcepticZP (talk) 16:43, 23 March 2009 (UTC)[reply]

Explicit implementation?

Hi guys, hope this is the right place for a comment (my first on Wikipedia): the Java code provided may be better off with an explicit "extend Window" in the decorator class declarations. The text above the code mentions that it is a requirement, but the snippet does not have it. Hope this helps. Taibr 03:39, 25 January 2006 (UTC)[reply]

I think the text may be incorrect. You can see that myWindow is a private variable of the Window class so it doesn't necessarily need to be a subclass. It is this variable which is to become decorated. As another example, one could argue that a beach ball class is a decoration on a sphere class but BeachBall doesn't necessarily need to extend Sphere (nor vice versa), just use a sphere and apply it's own "proprietory" attributes. There probably should be a Window interface, a new class that implements Window, and the Vertical/Horizontal scroller classes that implements Window and uses a variable which is of type {the new class}. Hopefully we can get more comments here.--Will2k 04:51, 25 January 2006 (UTC)[reply]

I am not an expert, but I think you're right: the original class and its decorated version should share a common superclass. This is required because you want to dynamically use (and cascade) decorators at run-time, yet having the resulting decorated class still of the same (super)type as the original class. So, you're right that your (concrete) decorator should not necessarily extend Window, so long Window and itself have a common superclass, which defines the utility methods you want to use. From what I see in the literature, the superclass "S" can be either abstract or an interface (in Java); and the concrete decorator may inherit an abstract decorator which is the one extending or implementing "S". The [second reference at the bottom of the page] has nice diagrams. But you're also very right on this: more comments would be good :) --Taibr 05:07, 27 January 2006 (UTC)[reply]

Depends on the lang. the types have to be related enough so that you can treat a decorated class and an undecorated class identically. So in java they have to share an interface or class hirarchy. In C++ they would have to share a class hirarchy. In Python/ruby they could be totally unrelated and just happen to have the same functions defined on both. bhunt 7/30/2007

Attribution to GoF book?

The Window / ScrollableWindow example seems stripped right out of the GoF Design Patterns book. Should this be attributed here, or is the example so ubiqutious that it doesn't need such treatment?

Mistake in the diagram

The diagram should show the operation() in the decorator tree instead of the doStuff() method. Oldani 17:30, 20 Mar 2007 (UTC)

same remark for Decorator:DoSomething() it should also be renamed Decorator:operation(). Malo —Preceding unsigned comment added by 82.127.102.32 (talk) 13:19, 8 November 2007 (UTC)[reply]

This diagram is indeed wrong and deceptive. Would anyone mind if we replace it with the one from the dutch wikipedia (the diagram is in in English). See http://nl.wikipedia.org/wiki/Decorator ? It's very clear to explain the Decorator pattern. --Marcvangrieken (talk) 15:11, 1 April 2008 (UTC)[reply]

Mistake in the diagram of the example

I think WindowDecorator is missing an "implements" link to Window: the corresponding Java code states "abstract class WindowDecorator implements Window", and the general example above shows the same relationship between Decorator and Component. Ma82 (talk) 13:02, 2 June 2008 (UTC)[reply]

Another thing with the diagram: drawVertical and DrawHorizontal should be private, since used only by the containing classes. —Preceding unsigned comment added by 213.30.132.28 (talk) 14:24, 4 November 2008 (UTC)[reply]

Too many code examples

This page seems to have started down an all-too-common path of turning into a repository for a multitude of redundant examples in numerous languages. We need to pick the one clearest example, be it in pseudocode or some actual language, and get rid of the others. --P3d0 (talk) 19:49, 9 January 2009 (UTC)[reply]

Ok, I've decided to be bold and delete all but the Python example. --P3d0 (talk) 13:52, 14 March 2009 (UTC)[reply]

Genericity of introduction

I think the introduction is not generic enough, i.e. uses too much implementation and language specific terms. Talking about delegating the method calls to the decorated object would be better. Also I don't really like the use of pointers, using reference might be better (I know, that in some languages, like C&C++ they both exist don't mean the same). Or just broadly describing it as the decorator delegating to the decorated object, period. The third thing is that the decorator doesn't have to extend the decorated object, it just has to have the same interface. This is clearly shown e.g. java example (not to talk about the dynamic language ones), where the WindowDecorator doesn't do anything but holds a reference to the decorated object.

A decorator base class can be useful for implementing decorators for complicated interfaces if it contained a default delegating implementation for all the methods. But it's a different question I think (and as I said in the java example the abstract base doesn't have any behaviour...) Atleta.hu (talk) 23:42, 9 March 2009 (UTC)[reply]