Question

Ok, this may seem like a dupe question, but if you bear with me and read the whole question, you see why I ask it.

I have seen many nice examples and explanations on the web and here as well, but I just cant get it. Its important for me to understand the whys and the hows, so instead of using some example from the documentation (BTW, I really suck when it comes to understanding Apple Docs, Im used with php.net documentation, with abundance of examples) because then I just don’t understand it.

I would like two classes, a gardenClass. It has an array with flowers, each flower is instantiated from the flowerClass. So, the flowerClass does not know what kind of garden instantiated it. It just screams for water sometimes.

So, if someone here could explain this for me, I would be really grateful!

I tried out and here is me having a go based on the info I got from you guys:

MyGarden.h

#import "Flower.h"

@interface MyGarden : NSObject <WateringDelegate>
{
    Flower *pinkFlower;
}
@end

MyGarden.m

#import "MyGarden.h"
#import "Flower.h"

@implementation MyGarden

- (void) giveWaterToFlower
{
    NSLog(@"Watering Flower");
}

- (void)viewDidLoad
{
    pinkFlower = [[Flower alloc] init];
    [pinkFlower setDelegate:self];
    [pinkFlower startToGrow];
}
@end

Flower.h

@protocol WateringDelegate <NSObject>
@required
- (void) giveWaterToFlower;
@end

@interface Flower : NSObject
{
    id <WateringDelegate> delegate;
}

@property (retain) id delegate;
- (void) startToGrow;
@end

Flower.m

#import "Flower.h"

@implementation Flower

@synthesize delegate;

- (void) needWater
{
    [[self delegate] giveWaterToFlower];
}

- (void) startToGrow
{
    [NSTimer scheduledTimerWithTimeInterval:10.0 target:self selector:@selector(needWater) userInfo:nil repeats:YES];
}
@end

I have not imported any UIKit or foundation, beause I tried to just do the stuff thats related to delegates here now…
So, is this correct?

Answer 1

A delegate is where you implement custom behavior for your app, that affects how another class (such as a plain-old object in the Cocoa framework) does its work.

In other languages that don’t use the delegates pattern you might subclass an object to change its behavior. Objective-C lets you do that as well, but the benefit of a delegate is that you don’t have to subclass each time you want to make a minor change, an object can be a delegate for multiple other objects.

So consider a controller class that owns a window with some controls, maybe a table of information, a toolbar, etc. You can set the controller to be the delegate of those controls, so that when the controls need more information about what they’re supposed to do they can look to your controller. You might want to customize how the window is resized, what happens when the user selects a row in the table view, how information is presented, and so on. Those are all calls the controls make to their delegate (your controller), using methods defined in their delegate protocol. If you’re lucky you can write all your custom code without having to subclass and split things up into multiple files.

Another benefit is that you only need to implement the delegate methods you care about. If the default behavior is fine, there’s nothing you need to do.

So in your example, the flower class would have some sort of delegate protocol with a “waterMe” method. The delegate (maybe the garden class, or something else altogether) could implement this however you choose, and it would only be called when the flower class needs it to. It’s worth noting though that delegation is most useful in frameworks, where you have an object that works in a generic way that may be overridden to accomplish different things. In your own code it’s usually more straightforward to add that custom behavior right to your own object, unless you truly are going to be using it in a generic way. In other words, don’t be tempted to spend the time making a class that can behave generically when in reality you’re only going going to make it behave in one specific way.