CODEWITHSUNDEEP
swiftinterfacedelegates
SirPaulMuaddib
SirPaulMuaddib

Reputation: 243

Delegates in Swift, do we need them?

I come from C# background, is it correct to say that delegates (not the C# version) in Swift are basically the same as interfaces in C#?

I see tutorials on using delegates in Swift, for passing data from one view controller to another view controller.

My question is this, can't one simply add a function to a swift class then have the view controller sub classed from that? Like

func ShowName(name : String)

And have the first view controller call the second controller using that function (that is in the class that the second controller is subclassed from).

Upvotes: 1

Views: 823

Answers (2)

Rob
Rob

Reputation: 437482

Technically, it is Swift protocols that are analogous to C# interfaces. A protocol is effectively a contract of what methods/properties a class will implement. Like C# interfaces, it can be used in delegation patterns, but it also has far broader applications.

But protocols serve a central function in delegation patterns (see Delegation discussion in The Swift Language or the Protocol or Delegation discussions in Cocoa Core Competencies), in which an object can designate another object with which it will communicate. The protocol simply outlines the precise nature of what an object requires of its delegate object, as well as what optional interfaces it supports with its delegate.

In answer to your question, when you have a delegate, you don't technically need to use a protocol, but it is best practice to do so. It makes the formal contract between the two classes very explicit, while at the same time keeping the two classes otherwise loosely coupled.

While it might take an extra two or three minutes up front to implement the protocol, it's almost always well worth the effort. It will simplify your maintenance of these classes in the future. So while you don't technically need to use protocols for your delegates and/or exchanging information between objects, I think you'll thank yourself if you do so.

Upvotes: 1

luk2302
luk2302

Reputation: 57114

You need delegates

No matter if you create some of your own you will not get around using them - they are builtin everywhere.

And yes, you could simply define a function in a viewController and call that one, but then the caller of that method has to now he is dealing with a viewController, nothing he really cares about. All he cares about is the fact that there is / has to be a function called showName.

If you are going to pass data forwards you do not have to use delegation since you know where you are going to pass the data to. But if you wan to pass data back you normally dont know where you came from -> second controller does not know and should not know he was presented by first view controller. He should work the same way no matter from where he got presented. And whoever feels responsible for him can and should assign himself as delegate which gets informed of changes or callbacks or whatever.

The subclassing you mention is basically that, but you can only subclass once, therefore if you want your class to be the delegate for a TableView, a CollectionView and your CustomView, you are going to have a bad time with only subclassing. What you are going to have to use is delegation via protocols

Upvotes: 0

Related Questions