Delegation take Two

I have to blog this RIGHT NOW because I totally understand Delegation. It only took seven weeks, but it makes a ton of sense. (I wrote this a week ago and am just getting around now to posting/editing it)

Remember how I was saying that there are a billion metaphors about delegation? Supposedly it's because something different will click for each person, but I have a theory that it's because people are terrible at explaining things. But never fear readers! I will set you straight and tell the entire coding community the right way to explain things. (because ya know, I know everything <--- this is is tongue in cheek)

Remember my Popeye and spinach metaphor? That is still apt. But let me tell you why it wasn't complete and then explain the metaphor that made all the other metaphors make sense. In my personal explaining metaphor, Popeye gets 'superpowers' (more methods) that allow him to do all sorts of super cool things. This is essentially what happens, but it's also not what happens. Prepare to think real hard dudes.

There are two really confusing things about delegation.  And a couple things with the Popeye metaphor that were incomplete. Popeye doesn't just get superpowers from the spinach. He opens a connection to spinach world where he gets superpowers. Those powers are still in spinach world, but because of the connection Popeye can access them.

The first confusing thing about delegation is the word itself. Because in delegation there is something called a delegate, and there is something that has a delegate method. Now this second thing doesn't have a name, it just has a method in it. (I'll explain why later)

Now you're going to want to call the one with the delegate method in it the delegate, right? WRONG! The thing you have to keep in mind with delegation is that it is essentially a connection between two things.  The one that is the delegate is the one that gets the response/info. I bet that last thing I said made no sense (because it doesn't), so let me go into detail.

Remember when I was talking about segues? I probably mentioned (or should have mentioned) that we have to use segues and delegation because different views and different objects on a view don't talk. Now if you are familiar with iOS, you might say, "BUT JEN, BUTTONS KNOW WHEN THEY ARE PUSHED". which is true. when you touch a button, it sends a message, which means it's probably using delegation (Boom. mind blown).

Some things in iOS already have features built into them that utilize hard to get concepts. So you don't really have to think about why a button sends a message, you just know that you can utilize it to go to a new screen or have something happen.

But if you break it down, the reason you're able to do stuff with buttons is because they send a message. So now you realize that you need to send a message between two things. Like I said before, unfortunately things don't communicate with each other unless you tell them too.

(I also think this is the core part of computers that people don't get. Computers don't know how to do things until you tell them. We've developed tools to make them more person intuitive... but they still are just using numbers to do things. Remember, the computer is a baby and doesn't know anything until you teach it or give it tools/skills/person attributes).

Now I'm off topic. Ok. The delegate and the thing with the delegate method have a relationship. For example, say we have three things, a house with a fancy number pad door, an atm, and a calculator.  All of these things share something in common: a number pad thing. That number pad thing is NOT the delegate. It is the one getting the messages and the numbers and the fun. The house and atm and calculator just need to know what keys are pressed when they're pressed. The number pad has a method that says what key is pressed.

so if the number pad thing isn't the delegate, what is? In this example, the house, atm, and calculator can become the delegate. That's right people! something can have multiple delegates!

In the process of writing this, I've confused myself. So let me set myself straight. The thing with the delegate method in it doesn't have a name because it can be anything. It can be a dog, or a view controller, or a piano. The delegate is what needs to know the info that the dog or view controller or piano know. Because like I said before, nothing in the ios landscape communicates.

(maybe they should see a relationship counselor... har har har).

So recap. I know when my toe gets stepped on. whoever stepped on my toe needs to know when that happens. So when my toe gets stepped on, I punch the person who stepped on it. The person I punch is the delegate. They receive the message that my toe is hurt.

Yea, the language of it is so stupid. I mean when you delegate something, you give the work to someone else. Since there is no noun for delegate, they don't call the person who pawns off the work anything. We should change that.

This is long and a little bit circular.

Here are the points that you should remember.
1. The language of delegation is hard. This is because anything can have a delegate method and anything can be a delegate.
2. Delegation is a connection between these two things. The thing with the delegate method gets a message and then sends it to the delegate. This message can be as simple as BUTTON WAS PRESSED! or as complicated as a complicated thing.
3. Setting the delegate (another confusing word thing with delegation) is essentially just telling the connection what it's between. So you tell the starting point that they are the delegate and the ending point that they are the delegate.

The metaphor that made sense? Delegation is a tunnel. Setting the delegate is just telling different things where the tunnel entrance and exit are. Then they can send things through the tunnel.

I finished my shawl. More knitting content tomorrow!