CODEWITHSUNDEEP
iosobjective-cmethodsdelegatesprotocols
Newbee
Newbee

Reputation: 3301

How does delegate call differ from normal method call ?

Whenever I wanted to inform something to parent class, I have used delegate instead of calling directly parent's functions. I have implemented like this...

eg:

    CustomClass *custom = [[CustomClass alloc] init];
    // assign delegate
    custom.delegate = self; // Here we are giving parent instance like normal method call.
    [custom helloDelegate];

In custom class, I have intimated parent like below....

-(void)helloDelegate
{
    // send message the message to the delegate
    [_delegate sayHello:self];
}

So my doubts , how does it differ from direct call?. Setting delegate variable with self is somewhat equal to giving the parent instance to child and let the child call the function whenever required, how does protocols help here or why do we need protocols? what is the advantage?

thanx

Upvotes: 4

Views: 1652

Answers (3)

Fogmeister
Fogmeister

Reputation: 77661

A working example of the advantage of using a delegate as opposed to using a direct relation.

Say you are writing a universal app. You have two view controllers in your code iPadViewController and iPhoneViewController and they both need to get data from a web service. So you create a class for you web service call webServiceDownloaderClass.

Now, both your view controllers need to be notified when the webServiceDownloaderClass has finished.

Your options here...

Option 1 strong coupling

In you iPadViewController you define a method - (void)webServiceDidGetArray:(NSArray *)array;. And in the iPhoneViewController you define the same method.

In order for the webServiceDownloaderClass to call these methods it now needs a reference to each of the controllers...

@property (nonatomic, strong) IPadViewController *iPadController;
@property (nonatomic, strong) IPhoneViewController *iPhoneController;

and then when it finishes it needs to determine which one to call...

if (iPadController) {
    [iPadController webServiceDidGetArray];
}

etc....

The cons here are that the view controllers are sort of defining what the web service class does when it is finished. Also, if you add another controller you have another property and no actual guarantee that the controller you referenced actually has the method you are trying to call.

Option 2 delegation

In your we service class you define a protocol.

@protocol WebServiceDownloaderDelegate <NSObject>

- (void)webServiceDidGetArray:(NSArray *)array

@end

and a delegate...

@property (nonatomic, weak) id <WebServiceDownloaderDelegate> delegate;

Now you are defining the actions of the web service class in the web service class. And you only need one reference to any class wants to be the delegate. Also, any class can be the delegate. So now both the iPad and iPhone controller can be the delegate and by conforming the the protocol they are "promising" the web service class that they will implement the required method - (void)webServiceDidGetArray:(NSArray *)array;.

Of course, this is just one case where delegates can be useful.

There are also cases for when you should possibly use a direct relationship rather than delegation.

Upvotes: 2

Hot Licks
Hot Licks

Reputation: 47759

A delegate call is not different from an ordinary method call!

What is different is how things are used, and this has nothing to do with the call mechanism. Delegates are used to decouple the definition of the code providing the delegate service from the code "consuming" the delegate service, so that the "consumer" (which, oddly, is usually a service on behalf of the delegate provider) does not have to be coded to know about THAT SPECIFIC delegate provider.

In Objective C delegates are commonly implemented using "protocols", but this is far from the only use of protocols. Objective C uses them extensively in providing common interfaces among the various Cocoa classes.

And, in limited circumstances, one can legitimately implement a delegate using a common superclass rather than a protocol.

If you have two classes that are part of the same development effort and which would not be likely to ever be used apart from each other, there is no need to employ the delegate "pattern" to facilitate communication between them, even though they are is a service-consumer/service-provider relationship. The only reason to do so would be "on spec", in case the "service" were ever reused unchanged in a different project.

Upvotes: 0

abbood
abbood

Reputation: 23558

your question is really about the difference between subclassing rather than implementing protocols (or interfaces in other languages like java)..

with delegates, you are implementing a protocol.. (which is a contract between the class referencing the delegate and the delegate itself).. this gives you more flexibility than subclassing because with subclassing you are automatically inheriting all the methods in the superclass (which is far more restricting than simply using some of the methods of another class.. in other words: subclassing = is a relationship.. whereas as implementing a protocol (same as delegation) = has a relationship.

if you read any book about design patterns.. they will talk extensively about the advantages of loose coupling your code and writing code that prevents modification but allows extension etc etc.. basically using delegation rather than subclassing is one way of fulfilling those design best practices.

Upvotes: 2

Related Questions