has some design flaws...which more or less defeats the purpose of the design pattern. Since, I kind of don't want to search in 13 page thread...has this issue been discussed?If not...I will provide a version I believe is more accurate.

Go for it By the way, if you joined the Community Composition Members group you wouldn;t need to search a 13 page thread since we have a forum here...

has some design flaws...which more or less defeats the purpose of the design pattern. Since, I kind of don't want to search in 13 page thread...has this issue been discussed?If not...I will provide a version I believe is more accurate.

Go for it By the way, if you joined the Community Composition Members group you wouldn;t need to search a 13 page thread since we have a forum here...

ok, where do I post my solution. is here ok....or there is something on the patterns site..I don't see

Oh well, I will post it here for now..should not crash to forum or anything.

Damn, it is hard to express yourself.
This is more or less my first try to do thorough explanation of my thoughts - writing an article sort of speech.
Hopefully I made it easy to read and comprehendable but you are the one to judge this.

Why Decorator Pattern?
Decorator pattern comes from the paradigm in OOP that each object should do
only what it is supposed to do. Just like Unix, do small and simple stuff and do it right.
To do complex stuff combine small elements and you get solid functionality that is
easy to maintain.

Our Scenario:
We have titles, pageFooters, and we have getData() to get the text of those...but...
What, if you want to log each time you get page's title - for whatever weird reason that is?
You don't add log() method in the title class because this is totally different functionality
that has nothing to do with titles (low cohesion).
For more on that take a look at.

What is "client code"?
Since I use the term here and there I would like to explain what I reffer to as client code
to avoid all confusion for those who does not know.
Lets take PEAR for example...it is library or whatever. The client code will be any
code that make use of PEAR library. like PEAR::isError or whatever.
If we say that we are building the library....we will strive to hide data as possible
to the client code, so we have greater control over our library. e.g. if our library (class(s))
have defined all methods as public...this will be total disaster as we cannot safely
change/refactor/improve our library - at anytime we might break someons implementation(client code).

At the top we have the interface pageElement. This is the key component.
Putting decoration asside for a minute we will have pageElement interface
and some concrete implementations that will... well..implement it (pageFooter,Title)

The interface is there to show what this class(s) (the implementations - Title,PageFooter) are intended
to do. You just build the object and use any public methods that the interface defines.
No methods not defined in the interface!!...all you could use on an object is described in the interface.
This is why it is an interface.

Now what happens if you need some more functionality, like logging for example when title data is retrieved.
Well, you build abstract decorator and then do some implementations of this
decorator (LogGetData,Color,Underline).

The abstract decorator should implement the pageElement interface because
this is what we are going to decorate after all, and we want to obey to this functionality.
The decorations happens transaprantly to the client code!!! No explicit calls to decorators are made!!!

Again, all decorator implementations(LogGetData,Color,Underline) have ONLY public methods
defined by the interface!!! Otherwise we will end up having $title->log(); which defeats
the purpose of the pattern.

Key moments:
- one top interface to which everyone obeys(pageElement)
- abstract decorator that uses composition... Stores pageElement implementation (decorated afterwards using cascade calls)
- decorator implementations (LogGetData,Color,Underline) - also having only publics defined
by the interface(this ensures you don't break the client code if you decide to remove the decoration at some point).
- each public method in the decorator ultimately deligates/returns data so a cascade call occurs.

Cons:
- all public methods of the interface should be implemented in each decorator implementation (if only to just deligatte to parent).
Meaning too many public methods are getting harder to maintain. It is time to rethink your objects (maybe they do more than they should)

Conclustion...what was achieved:

Lets say someone should use this class/library we just build.
Our documentation will througohly describe the interface pageElement,
mentioning that there are decorators to it...and can use the *_Factory class(s)
to build fancy objects.

So the devoloper will be like:
aha Decorator - I know the idea of this...let see how can I use it. Ok, some factory
classes, good I don't need to look at all those decoratores one by one to know how to build fancy stuff.

And what can I do with the fancy objects? Let me check the interface...aha getData()
Cool, not much but with decoration it will come out to be one fancy getData - solid.

Hence, no need to know specifics of decorators! Know what an object could do (the interface)
so no need to look at source code and stuff. one factory class to learn to know
how to build all kind of fancy combinations.

The purpose of the wiki is to allow for others to make necessary changes. Post there. Also, look into joining the Community Composition Contributors group in our forums. To do that, click on the Usergroups links at the top of any forum page (or you can get there by clicking here). Select the Community Composition Contributors group, click View Information and then choose subscribe.

The purpose of the wiki is to allow for others to make necessary changes. Post there. Also, look into joining the Community Composition Contributors group in our forums. To do that, click on the Usergroups links at the top of any forum page (or you can get there by clicking here). Select the Community Composition Contributors group, click View Information and then choose subscribe.

ok, I added it to wiki.
Call me stupid, but I don't see how to subscribe for this group There is no such link or anything.
Also, would be great if the UML diagramm could be somehow moved to a more permanent place....because I don't know for how long it will stay there.

Call me stupid, but I don't see how to subscribe for this group There is no such link or anything.

d11 is taking care of it for you, but was this instruction not clear?

Everah wrote:

Also, look into joining the Community Composition Contributors group in our forums. To do that, click on the Usergroups links at the top of any forum page (or you can get there by clicking here). Select the Community Composition Contributors group, click View Information and then choose subscribe.

Call me stupid, but I don't see how to subscribe for this group There is no such link or anything.

d11 is taking care of it for you, but was this instruction not clear?

Everah wrote:

Also, look into joining the Community Composition Contributors group in our forums. To do that, click on the Usergroups links at the top of any forum page (or you can get there by clicking here). Select the Community Composition Contributors group, click View Information and then choose subscribe.

instruction was crystal clear...but
when I got in there there was just no subscribe button....no idea if it was disabled...session gone bad or whatever just don't know.
Next day I think...I went there again and there was the subscribe button...clicked, pending.... d11 wrote he will take care of that manually...and I guess he just accepted my subscription then.
Cheers

As of 8:46 am, 11 Sep 2006, Maugrim has returned from limbo. Yep, I even have full internet access once again. Currently clearing through my email (two months worth!), recovering from a weekend party celebrating the end of those examinations I was taking last week (and studying for between work for the last two months), and getting to grips with the accumulation of mail that the postman managed to cram into my postal slot.

I am about three months out of touch, completely unaware of most things that have been happening in these here PHP parts. I'll be my usual forum slave self in about an hour. Good to be back - the internet withdrawel was a killer .

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum