In Objective-C and iOS, it seems that delegates can go any direction?

Question

I was a bit surprised at first that UIView's drawing is helped by CALayer, but CALayer's delegate is actually UIView. It seems that the relationship is reversed.

But is it true that, delegate has no "master commander" or "ownership" relationships... it can go any direction: such as, Class A can have a delegate which is Class B, and at the same time, Class B can also have a delegate that is Class A.

Even more, there can be multiple delegates, which means, an object needs help from several other objects.

It is kind of similar to the physical world, that a CTO can delegate the "Technical ability test to interview someone" to David, and now David is a delegate for providing a score of 1 to 10. But David can delegate a requirement met or not back to the CTO (a boolean) that "I can only interview the candidate for Javascript, I will agree the new candidate can be hired and agree to work with him if you find out he is good with scalability issues because our group need such a person" -- and David is delegating this back to the CTO.

So in Objective-C (and probably any language too), there can be multiple delegates, and they can go any direction, and the main idea is just for some "help" that the original object doesn't know how to handle. Is that true?

Answer 1

Delegates in iOS are not really like in real life. The delegates don't actively tell objects how to work, but rather reactively instruct objects as to how they should operate, and receive updates about the status of objects.

The delegate is in place to monitor the status of the objects it is delegating, and to provide instructions (when necessary) on how the object should perform its tasks. Your right in saying that there is no specific ownership, like class A can be a delegate for class B while class B is delegating class A. This is perfectly fine.

There are four main types of delegate methods that both provide the delegate with information about the status of the object, and request instructions from the delegate. PeyloW describes them very well in his answer here.

All of this is a roundabout way of saying that yes, you are correct.

Answer 2

Delegates help the object oriented principle of encapsulation. Take UIApplication, for example. Have you ever subclassed it? It's possible for some rare cases but most of the time it provides vital functionality that might be affected by a user's careless subclassing. Thus, the delegate pattern emerges. The UIApplication will behave exactly as it was intended internally, and take its cue from the delegate for certain predefined cases that are expected to happen consistently. Another function of the delegate is related to events (notifications in obj-c). The object will inform its delegate of certain events that might be of interest to an outside observer (for example, UIScrollView begin and end scrolling).

However, usually there is only one delegate, and not multiple as you say. That's not to say it is impossible but most of the time it is unusual (what would happen if two delegates were feeding cell heights to a UITableView?)

So in your example, the CTO has a set of criteria that he uses internally without informing David, but for one of them he needs David (or someone other than himself) to perform some task and report the result. This result could be optional (David has a chance to decline and the CTO will use his own judgement) or required (if David says no, he will lose his "job"). In either case, the point is there is no need to be concerned with what the CTO thinks about internally (just as there is no need to worry about how UIApplication does what it does). The important functionality is encapsulated from the developer.

Answer 3

Yes delegates can go in any direction, since being a delegate of something really only means that it will perform certain methods on behalf of the "main" class.

This might be related to what you asked:

Multiple Delegates in Objective C

So in Objective-C (and probably any language too), there can be multiple delegates, and they can go any direction, and the main idea is just for some "help" that the original object doesn't know how to handle. Is that true?

Almost, it depends on the class and the purpose like this:

@optional methods

These will help customize the behavior of the method if overwritten but are not really necessary or they already have a default implementation.

@required methods

These are crucial and as you said the main class doesn't know how to handle them.

Answer 4

It's really not the language, but the framework (Cocoa) that establishes the pattern of delegates.

Delegates are, however, usually implemented using a language feature called "protocols". A protocol in ObjC is a list of method declarations that a class can promise to implement. Each method within the protocol can be either optional or required. If a class adopts a protocol but doesn't implement a required method, the compiler will signal an error.

Protocols, being without implementations and not tied to the class hierarchy, are ideal for the loose relationship that exists between a delegate and its delegator. Any class can adopt any protocol, or many, announcing that it is will implement the methods declared there. If the protocol outlines the interface between a delegator and delegate, then the class is ipso facto a delegate.

The reason that any object (rather than class) can (usually) be used as a delegate is that delegate properties/ivars are usually typed id. This is the generic object pointer, allowing any type of object to be assigned, which is in keeping with the pattern of the delegate -- all the delegator needs to know is that its delegate responds to the messages it will send. Any other behavior is not any of its business.

Class A can have a delegate which is Class B, and at the same time, Class B can also have a delegate that is Class A.

Sure, potentially, as long as they each know that the other implements the necessary methods. Off the top of my head, I can't think of a reason to do that -- delegates in Cocoa are usually controller objects, allowing the modification of behavior of framework model classes without subclassing. The delegator/model will ask its delegate/controller for permission to do something, or notify the delegate that it is about to or has just done something.

So in Objective-C (and probably any language too), there can be multiple delegates, and they can go any direction, and the main idea is just for some "help" that the original object doesn't know how to handle. Is that true?

I really don't know what you mean by "go any direction". It's not so much "help", either; generally speaking, an object that has an associated delegate protocol doesn't require a delegate to be present -- it will work perfectly well without it.

Answer 5

A delegate is just a way to provide a function you're invoking access to data and algorithms which you wish it to use. It's nothing magical, and there's no "standard" involved -- just a particular way to make use of ordinary objects. Other languages use different terms (eg, "event handler") for the same concept.