Best practice for setting variables / functions when returning from delegate?

🎤 General Discussion Swift
1

Hi All,

I’m becoming more and more comfortable with delegates, but I’ve been wondering if there’s a best practice for using the data coming back from them.

Here’s the use case.

VC1 → VC2 delegate w/ table view → dismiss VC2 → VC1

I’ve been using a couple of different ways… the first being an observer, so…

var modelTableSelection: String? {
        didSet {
            myTextField.text = modelTableSelection
        }
    }

The other is just to call a function on the delegate…

func returnedFromDelegate(theString: String) {
   myTextField.text = theString
}

Perhaps I’m just being overthinking this - but I’m never really happy with how verbose some of these methods get.

Are there any other design patterns I should investigate for using the data returned from a delegate?

Thanks!

2

Personally, I don’t believe in the delegate pattern. I think it only makes sense in a language that can’t store functions. We don’t use those anymore. Your mileage may vary, but I never make my own. I just use closures.

Would passing {[unowned myTextField] in myTextField.text = $0} over to your delegate not be a good solution for you?

One more tip: the use of “my” and “the” is not needed. Just lowerCamelCase versions of the types they are will work fine in Swift. You could even use the exact same name for parameter and parameter types (e.g. (string: string), where string is perhaps a protocol), but typically, the casing will vary between the two.

3

Remember the intent of the delegate pattern - one object requires something to be done but does not care how it is done, responsibility for the task is delegated. It is true we often use them for the convenience of communicating against the flow, and closures can do some of the same things as delegates but since you are implementing what is in the closure you certainly have to care about the implementation.

4

Hi @jcatterwaul – I was just using ‘my’ and ‘the’ as examples… those aren’t in production code. :slight_smile:

re: delegate pattern vs closures – It certainly goes against the ways I was taught to implement such workflow, but that’s an interesting approach. I appreciate the feedback.

5

Closures are not different than what you were taught. They are the specific subset of delegates that allow an implementation of the delegate pattern that doesn’t require you to make objects. The objects used to be necessary, but aren’t anymore. Try it out for yourself if you don’t take my meaning; I’ll help you through it.

I like the way it’s put here:
http://letoverlambda.com/textmode.cl/guest/chap2.html

Closures are one of those few curious concepts that are paradoxically difficult because they are so simple. Once a programmer becomes used to a complex solution to a problem, simple solutions to the same problem feel incomplete and uncomfortable. But, as we will soon see, closures can be a simpler, more direct solution to the problem of how to organise data and code than objects.