fs_tigre
fs_tigre

Reputation: 10738

Understanding the Relation Between Delegation and Protocols

I know there are a lot of similar questions here but I still need some clarification about this concept.

First of all let me start by saying that I do understand what protocols are and how to use them, what I'm having problem understanding is delegation. I do understand that delegation is when one object in a program acts on behalf of another object, sound very simple but hard to see the whole picture.

1- Is delegation just a way to let the compiler know where to look for the code that will be manipulating the object (UITableView etc.)?

2- Do delegation and protocols work together?

3- Can delegation exist without protocols? If yes, can you show me an example.

4- When we declare a protocol and a class conforms to it, can we say that this class conforming to the protocol is delegating on behave of the protocol?

How much of the above is true?

Thanks a lot

Upvotes: 0

Views: 148

Answers (2)

KIDdAe
KIDdAe

Reputation: 2722

1- Is delegation just a way to let the compiler know where to look for the code that will be manipulating the object (UITableView etc.)?

No, delegation is a design pattern. It's just a concept.

2- Do delegation and protocols work together?

Yes they work well together and it's probably the best practice to use protocol for your delegate.

3- Can delegation exist without protocols? If yes, can you show me an example.

Yes you can. Delegation concept is just to remove intellect of an object and put it in the delegate. For exemple an UITableView does not know how many row it has, or what to do when a cell is clicked, so it asks to its delegate. But the delegate is still another object.

It's better if it implements a particular protocol, but you can do it without.

For exemple :

I've a MyView that is a subview of a MyCustomViewController.

MyCustomViewController.h

- (void)myViewIsTouched;

MyView.h

@property (nonatomic, weak) MyCustomViewController *delegate

MyView.m

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event {
    [self.delegate myViewIsTouched];
}

There is no protocol in this exemple, but it's still a delegate. (A better way is still using a protocol instead of declaring the method in the .h)

4- When we declare a protocol and a class conforms to it, can we say that this class conforming to the protocol is delegating on behave of the protocol?

I'm not sure about what're saying. But protocols and delegate are not the same thing. An object implementing a protocol does not mean that it's a delegate.

Upvotes: 3

Alex
Alex

Reputation: 8991

  1. Delegation allows objects to be able to change their appearance / state based on changes in other parts of your application. Setting a delegate property on an object will allow the compiler to do some checks at build-time.

  2. Delegation is often achieved by using protocols, since it allows the delegate object to be of any class instead of a sub-class of a class with specific behaviour.

  3. Yes, but this would result in your classes becoming tightly coupled since Foo needs to know about Bar and vice-versa. Using protocols allows you to use any class, hence id property, resulting in a loosely coupled system.

Example:

@class Foo;
@interface Bar : NSObject
- (void)respondToSomeAction:(Foo *)obj;
@end

@implementation Bar 
- (void)respondToSomeAction:(Foo *)obj {
   NSLog("responding to %@",obj);
}
@end

@interface Foo : NSObject 
@property (nonatomic, weak) Bar *delegate
@end

@implementation Foo
- (void)someActionTriggered {
    [self.delegate respondToSomeAction:self]
}
@end
  1. When a class conforms to a protocol, the class is compelled to adopt the behaviours of the protocol (implement the methods). It only becomes a delegate if it is given some task to do on behalf of another class, e.g. supply the number of rows in a table.

Upvotes: 1

Related Questions