Wrox Programmer Forums

Need to download code?

View our list of code downloads.

Go Back   Wrox Programmer Forums > PHP/MySQL > BOOK: Professional PHP Design Patterns
Password Reminder
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read
BOOK: Professional PHP Design Patterns
This is the forum to discuss the Wrox book Professional PHP Design Patterns by Aaron Saray ISBN: 978-0-470-49670-1
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: Professional PHP Design Patterns section of the Wrox Programmer to Programmer discussions. This is a community of tens of thousands of software programmers and website developers including Wrox book authors and readers. As a guest, you can read any forum posting. By joining today you can post your own programming questions, respond to other developers’ questions, and eliminate the ads that are displayed to guests. Registration is fast, simple and absolutely free .
DRM-free e-books 300x50
Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old February 7th, 2010, 02:19 PM
Registered User
Join Date: Feb 2010
Posts: 1
Thanks: 0
Thanked 0 Times in 0 Posts
Default Differences between Delegate AND Strategy Pattern

First, sorry for mistakes, I'm from Italy.

I don't understand very well the differences between these 2 pattern, they seems to be very similar.
In both of them you move the responsability ( you "Delegate" ... ) of an action to another specific class, in both of them you call a method of a property of the main object.

I look on other Design Patterns book (i.e.: GoF ) and I don't find anything about Delegate Pattern ... could you explain me what are the differences?

By the way, the Delegate pattern seems to be the "simple" version of Strategy Pattern ...!

Reply With Quote
  #2 (permalink)  
Old February 8th, 2010, 05:18 PM
Wrox Author
Points: 118, Level: 2
Points: 118, Level: 2 Points: 118, Level: 2 Points: 118, Level: 2
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: Sep 2009
Location: Milwaukee, WI
Posts: 15
Thanks: 0
Thanked 4 Times in 4 Posts


Thanks for the question!

The question is a good one. It took me a little bit to understand the difference between these two patterns (as well as similar building patterns like factory).

This is the important thing to notice: The delegate pattern is about objects that are created to help delegate the decision making responsibility. This means a set of qualifications need to be analyzed to determine the end result. When the Strategy pattern is introduced, it is more of a context based object. So instead of more explicit analysis, its more implicit.

You might think of it like this...
In a delegate pattern, you may choose between two classes, one called LowerDelegate for objects with a lower value, and one called HigherDelegate for those with higher values. In the strategy pattern, the object is instantiated with a context, so it knows if its ahigher or lower object. Then, the strategy initiation portion of this may be the new object being created by calling ContextDelegate (where Context is an internal value of either Lower or Higher)... see how there is no decision making? (of course error handling should be in place in case something like NULL comes through - probably isn't a NULLDelegate class!)
aaronsaray.com || <-- yeah... try it.
Reply With Quote
  #3 (permalink)  
Old April 28th, 2010, 05:40 PM
Friend of Wrox
Points: 1,749, Level: 16
Points: 1,749, Level: 16 Points: 1,749, Level: 16 Points: 1,749, Level: 16
Activity: 0%
Activity: 0% Activity: 0% Activity: 0%
Join Date: Jun 2007
Location: San Diego, CA, USA.
Posts: 477
Thanks: 10
Thanked 19 Times in 18 Posts

So is the Delegate pattern concerned with object instantiation? Is it a variant or synonym for the Factory pattern then? I've tried to figure out .NET delegates (which I thought were more related to the Observer pattern though it's not an exact match), or are they completely unrelated to the Delegate pattern?

I've been in situations where I needed to manage different end products so I created a class for each one and then created a factory to encapsulate the decision making code. Then when you need to instantiate an object, you don't do it in plain sight, you call on the factory, pass in your parameters (if any) that tell the factory what kind of object you need, and let the factory worry about instantiation.

My understanding of the Strategy patten was that it allows you to encapsulate a particular behavior that a class has, then compose the behavior into the main class. This gives you the option to build variations of the behavior to 1) define different behaviors for different subclasses and 2)
swap / change behaviors at run time if desired.

Whatever you can do or dream you can, begin it. Boldness has genius, power and magic in it. Begin it now.
-Johann von Goethe

When Two Hearts Race... Both Win.
-Dove Chocolate Wrapper

Chroniclemaster1, Founder of www.EarthChronicle.com
A Growing History of our Planet, by our Planet, for our Planet.
Reply With Quote

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

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 Off
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Design Strategy zoltac007 ASP.NET 1.x and 2.0 Application Design 2 October 3rd, 2006 11:56 AM
DirectoryInfo.GetFiles(pattern): search pattern fo arif_1947 VS.NET 2002/2003 1 October 19th, 2004 11:59 PM
Business Delegate Pattern for Accessing Remote EJB mlumsden BOOK: Expert One-on-One J2EE Design and Development 1 September 25th, 2003 03:31 PM

All times are GMT -4. The time now is 05:16 AM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.