CODEWITHSUNDEEP
swiftdelegatesprotocols
Laurence Wingo
Laurence Wingo

Reputation: 3952

In Swift, does an object conforming to a protocol absolutely need a delegate variable in order to work with the protocol?

I'm working through another UITableView tutorial and it always my learning process always reverts back to the idea of protocols and delegates. The area that is a bit confusing is the idea of a delegate variable of that type protocol. It seems that when programming, if you choose to make an object conform to a protocol then it appears that you need to create a variable called delegate as well (of the type protocol)? Part of me says this isn't true that we have to create this variable but I'm not sure plus I'm not fully understanding the reason for this variable.

I comprehend that in order for an object to conform to a protocol then it needs to implement certain variables and/or methods. I always get confused when I see a tutorial that creates a variable called delegate within the same object. If the object already conforms to the protocol by implementing the variables and/or methods, then what is the reason for creating a variable called delegate and setting the type to that of the protocol?

Upvotes: 0

Views: 231

Answers (2)

matt
matt

Reputation: 535202

If the object already conforms to the protocol by implementing the variables and/or methods, then what is the reason for creating a variable called delegate and setting the type to that of the protocol?

The whole purpose of the protocol in the protocol-delegate pattern is that the only thing this class, which is going to be sending delegate messages to the delegate, needs to know or care about, is that the delegate is an adopter of that protocol — i.e., that it implements the variables / methods. This class doesn't need to know the actual class of the delegate; it just needs to know that that the delegate can be sent the delegate messages.

Thus, it's all about the compiler. The object acting as delegate may conform to the protocol, but the compiler doesn't know that unless this variable is typed as a protocol-adopter. And if the compiler doesn't know, it won't let us send delegate messages to the delegate object! So that's how we type it. That's the minimum the compiler needs to know in order to allow us to send the delegate messages.

Upvotes: 1

Rob Napier
Rob Napier

Reputation: 299355

No, protocols are a separate concept from delegates. The delegation pattern in Cocoa generally uses a protocol, though it doesn't have to. Before ObjC 2, almost all delegation was done with "informal" protocols (i.e. there was no actual protocol defined). In Core Foundation and Swift, delegation can be implemented with structs rather than protocols (this is somewhat common in Core Foundation, but more rare in Swift today).

There is a tradition in Cocoa of using a property called delegate which you use for the delegation pattern (also called the "Strategy Pattern" in some languages). It is an object that tells you how to behave (you "delegate" decisions to it). Cocoa has a long history of consistently naming things, and using the name delegate is very helpful because it also implies to the reader that it's a weak reference (again, by tradition). Sometimes there is also a "data source" which is exactly the same as a delegate, but provides data rather than behavior and configuration.

But protocols are much bigger than this. A protocol is just a promise to implement methods. It can be used for many things beyond just delegation.

Upvotes: 1

Related Questions