Comments on: Decorator Pattern http://www.phpdesignpatterns.com Tutorials and Examples of Design Patterns in PHP Wed, 25 Aug 2010 02:53:49 +0000 hourly 1 http://wordpress.org/?v=3.0.1 By: thinsoldier.com http://www.phpdesignpatterns.com/design-patterns/pattern-decorator/comment-page-1/#comment-4 thinsoldier.com Fri, 05 Feb 2010 21:20:21 +0000 http://www.phpdesignpatterns.com/?page_id=44#comment-4 [...] This is a comment I had about an article on the Decorator pattern [...] [...] This is a comment I had about an article on the Decorator pattern [...]

]]> By: thinsoldier http://www.phpdesignpatterns.com/design-patterns/pattern-decorator/comment-page-1/#comment-3 thinsoldier Fri, 05 Feb 2010 21:11:14 +0000 http://www.phpdesignpatterns.com/?page_id=44#comment-3 Very easy to understand but I think some people may overlook the importance/usefulness of the decorator pattern since all you're doing in the examples could be accomplished by just concatenating P and /P around the getData() wherever it is you were going to display it. I find the decorator pattern is best for when you have a lot of parts to the data that need a lot of manipulation of their values and a lot of html but not so much html that it warrants a full page/template/view. For example in my (poorly written) real estate site I have an object that represents a property for sale in the listings table of the DB. All 126 fields of the property record! When it's time to show info about the property to a visitor I only need to show them about a dozen fields. But most of those fields need to be manipulated. I need to ucfirst() the property status text, convert the price to Euros/Pounds/USD/BSD, attach the http://www.site.com/listings/... onto the permalink text of the listing, convert 3.5 into "3 1/2 Bath", convert the square feet values into Acres if they are over 1 acres in size and lots of other stuff. Also all these fields had to be wrapped in html tags and ids and css classes etc. At first I had all that stuff as part of the code that happens _before_ the data is saved to the database. Then other clients came along who wanted the same system (but different) and I realized a lot of those manipulations were only relevant to the site visitors. So then I put those instructions in the main class file as $listing->displayOverview() method. But then some more clients came along who wanted something other than the default set of info in the default format. Some clients wanted the category value to link to a search results page of everything in that category. Some wanted the neighbourhood value to do the same. Some didn't want the category or neighbourhood value to be shown. Sure I could have just use css to hide the neighbourhood span but some high end clients don't want anyone to know where their house is located so the neighbourhood/address values weren't allowed to be anywhere in the markup. They had to be taken out at the code level. It unfortunately took a looong time and a lot of clients on this system to realize I needed to take this segment of my code and turn it into a custom decorator for each client that needed one. Before that realization, at one point I had a site identifier variable and a ton of IF statements strewn throughout the code that made it a nightmare to read! For another good example of decorator usage see this Zend Framework Zend_Form screencast (requires having a zend.com account): http://www.zend.com/en/webinar/Framework/webinar-leveraging-zend_form-decorators-20091216.flv Very easy to understand but I think some people may overlook the importance/usefulness of the decorator pattern since all you’re doing in the examples could be accomplished by just concatenating P and /P around the getData() wherever it is you were going to display it.

I find the decorator pattern is best for when you have a lot of parts to the data that need a lot of manipulation of their values and a lot of html but not so much html that it warrants a full page/template/view.

For example in my (poorly written) real estate site I have an object that represents a property for sale in the listings table of the DB. All 126 fields of the property record!

When it’s time to show info about the property to a visitor I only need to show them about a dozen fields. But most of those fields need to be manipulated. I need to ucfirst() the property status text, convert the price to Euros/Pounds/USD/BSD, attach the http://www.site.com/listings/... onto the permalink text of the listing, convert 3.5 into “3 1/2 Bath”, convert the square feet values into Acres if they are over 1 acres in size and lots of other stuff. Also all these fields had to be wrapped in html tags and ids and css classes etc.

At first I had all that stuff as part of the code that happens _before_ the data is saved to the database. Then other clients came along who wanted the same system (but different) and I realized a lot of those manipulations were only relevant to the site visitors. So then I put those instructions in the main class file as $listing->displayOverview() method.

But then some more clients came along who wanted something other than the default set of info in the default format. Some clients wanted the category value to link to a search results page of everything in that category. Some wanted the neighbourhood value to do the same. Some didn’t want the category or neighbourhood value to be shown. Sure I could have just use css to hide the neighbourhood span but some high end clients don’t want anyone to know where their house is located so the neighbourhood/address values weren’t allowed to be anywhere in the markup. They had to be taken out at the code level.

It unfortunately took a looong time and a lot of clients on this system to realize I needed to take this segment of my code and turn it into a custom decorator for each client that needed one.

Before that realization, at one point I had a site identifier variable and a ton of IF statements strewn throughout the code that made it a nightmare to read!

For another good example of decorator usage see this Zend Framework Zend_Form screencast (requires having a zend.com account): http://www.zend.com/en/webinar/Framework/webinar-leveraging-zend_form-decorators-20091216.flv

]]>