9. A little bit more (okay it's actually quite a bit more) on methods: their structure and how to call them

If you have been following along with my posts, we just went over what global variables are, and how to use them. We put them inside our viewDidLoad method, and assigned some values to show that we didn't need to declare anything, and that was all fine and everything, but what is the point? The answer is that without moving onto a different method, or scope, there isn't a point to class variables, otherwise we could just use local variables, right?

In this post we are going to talk in detail about basic method structure, and then we are going to go ahead and make several calls to clarify and cement how methods and control work together to run your program. First, let's start out with the basic structure of a simple method declaration:


What can you infer about the above line of code? Is it doing anything? Not really. Where do you think this declaration would belong? If you said the header file you are right. The above line of code is simply declaring a method. So before we dive into what the parts of a method declaration mean, I want to make sure we understand better how methods are used. So here is an example that will hopefully clarify things a little.

Lets imagine that you are the manager of a small business. You make and sell...cookies (cookies? yep :). You are sitting in your office doing things that managers do, and you are working on a to-do list you have made for yourself. These are the two things you need to do:

1. You need to tell your secretary to give you a list of your appointments for the day.
2. You need to tell your secretary to forward all calls to your answering machine.

Ok in case you are wondering what in the world I am talking about here, stay with me, it will all make sense shortly.

Lets start helping our manager with his to-do list. His first task is to get a list of appointments from his secretary. How is he most likely to achieve this? Well, odds are he is going to call her on the phone and make the request. So what will the result of his request, or call be? A list of appointments, right? That is what he hopes to achieve by making the call.

So lets move from our fictional story for a little bit and apply this same request to how we would do it in code. The manager is in one place (we'll say in the viewDidLoad method in code terms), and he needs to get something done. So the manager makes a call to his secretary and makes the request, or calls the appropriate method. We will go ahead and name this method getReportFromSecretary. We need to keep in mind when we are writing methods that it is best to keep the purpose of a method concise and direct. The purpose of this method is to get the report and then return it to the person who called it. Does that make sense?

I think now is a good time to dissect the way that we declare basic methods so we can better understand their purpose. Let's look again at what our method declaration looks like:


This basic method declaration can be broken up into two basic parts: the return type, and the method name. When put together, these two parts make up what is called the method signature. The code snippet right above is a perfect example of the method signature. Get used to that terminology because I will use it often. In the header file, and in the implementation file, a method is declared and implemented using the method signature.

We mentioned before that the purpose of a method is to run a specified block of code that achieves a specific purpose. So the idea behind calling this getReportFromSecretary method in code is that some code inside of that method would take care of getting that report for us, and then return the report back to us.

Can you conceptualize that easy enough? You call a method to run a specific block of code that achieves a task that you have designed it to do, and if applicable, it returns something back to you. This is very important. In the example above, we are saying that this particular method has a return type of NSString *. That means that I'm saying the report we are expecting back will be an NSString. Can you think of any other return type possibilities? All of the basic data types we have already talked about work great as return types for methods. Can you remember what they are? Integers, doubles, and booleans are data types you could also use as return types. So lets go ahead and flesh out a very basic implementation of the method we have declared above:


The main point I am trying to illustrate isn't how we would go about getting a report generated, so I haven't included any code about that type of operation, but I am illustrating the basic idea behind a simple method. Once the above method is called, control enters the scope of the method and begins to execute the code you have written. In this case it would be to put some kind of a report into an NSString variable. The last line of executable code, is very important. This is called the return statement. This line of code is what actually returns the variable to whoever called it. It doesn't need to be at the end, but it often is. So you might be wondering about what happens with the variable once it is returned, where does it go? To answer that we need to examine how we go about calling methods.

Before we put our method call into context, lets examine how we call methods in a generic sense. Here is the syntax:


Thats it! That one line of code is how you call a method. So what is the self business all about? Self is basically referring to the fact that you are calling a method in the class that you are currently in, the ExampleViewController. It is important to specify that because you can call methods on different classes as well. We'll save that talk for another day. So by saying self, we are basically saying that we are going to reference a method that we have declared already up in our header file. Think about that for a second, does that make sense? Self simply refers to the class you are in, it is a whole lot easier to write out that the long name of the class ;)

The next part of making a method call is to send a message to self (ExampleViewController) telling it which method to call. It knows which method to call depending on what name you send it in the message. In our case, we are sending self a message to execute the getReportFromSecretary method. The syntax for this operation is really important, so let's go over it again. Inside of two square brackets, you have a class on the left, and the message on the right. It is as if you are feeding the class on the left the message on the right. It digests your message, and does what you tell it to. You will see that pattern over and over and over again, so be sure you are comfortable and familiar with what is happening.

Now that we have discussed the basic approach to calling methods, lets put it into context. If you remember, we said our doctor has been hanging out in the viewDidLoad method, so that is where the call for the report is going to originate from. How does this look:



Does that seem right? You remember that our method has a return type of NSString, what is happening with our NSString? Are we doing anything with it? Nope. The above implementation isn't really going to work for us. We need to be sure that we are respecting the fact that the result of this method call is an NSString. We need to do something with the value being passed back. Any ideas? Lets assign it to a local variable (it could also be a class variable)!

That looks much better! Can you see what is happening? We are declaring a local variable (how do we know it is local? Because the actual data type declaration is taking place inside the scope of the viewDidLoad method, not up in the header file where the class variables go), and setting it's value to the result of the getReportFromSecretary method call! How cool is that?! The above line of code is very important to digest properly, so make sure you are completely clear on what is happening.

We can now cross the first item off on our to-do list and move on to the next one! The next item that our manager needs to take care of is telling his secretary to forward all of his calls to his voicemail for a while. Not thinking about any code, what would he do in real life? Call his secretary on the telephone, let her know what he wants her to do, hang up, and he's done, right? Lets see if we can represent this process in code.

For this next method, we can go ahead and give it a name of forwardAllMessages. Thats a descriptive enough title. You need to remember that it is always a good idea to make your method names as descriptive as possible so that when you or someone else comes to use the method, they can quickly get an idea of what the method's purpose is. We have the first part of our method figured out (the name), what about the second part, what else do we need? A return type! Lets think about this scenario for a second, what is the manager expecting to get back? A report verifying that she has done what you asked her to? Probably not. In all reality, he probably isn't expecting anything (tangible) back. So if we aren't expecting anything back as a result of a method call, how do we represent that in the method signature? The answer is void. That should look familiar. In many of the methods that we have seen already, the return type is void, meaning that there isn't a variable or value that you need to pass anywhere after you're done with executing the method.

So assuming that our manager is still being represented within the viewDidLoad method, and remembering to keep the code from our first task, lets go ahead and tackle our second task in code. Here is the implementation of our forwardAllMessages method:


How do you feel about that? Do you see why we don't need a return statement in this method? Our return type is void, meaning that the caller of this method shouldn't expect anything back. Lets take a look at how we would make the method call in viewDidLoad:


That's it! Because there is nothing coming back, we don't need to do any local variable declarations or anything. We simply are making the method call that will handle the code necessary to forwarding all of your messages. And just like that we are finished with our to-do list.

Methods are an essential part of of computer programming. You need to make sure that you understand very clearly their purpose. Methods are used to delegate routine actions to areas of code that are designed to handle them. To make sure that these concepts are crystal clear, I want to go ahead and build on this example in the test app that we are building, and start making and tracking method calls.

No comments:

Post a Comment