This final post on basic method calls is going to revolve around calling methods with return types. Do you remember what those are? The return type of a method specifies what data type the result of your method call is going to be. We have just finished up using a number of methods that have a void return type, or that don't return anything. We are now going to examine the use of methods with basic data return types. Let's start by changing the methods in our .h file to look like this:
As you can see, I have changed up the methods that we are going to run quite a bit. Besides the method names, what else is different? How do you know what a method's return type is? The area in the parentheses at the beginning of the method signature is where you can specify what a method's return type is.
Just to mix things up, I decided to use a whole bunch of different methods and return types to accomplish a pretty simple task. It's ok though because these exercises are for learning principles, not accomplishing awesome tasks yet.
Now let's take a look at our implementation file and see what we are going to do with our methods we have declared:
Let's take a look at what we are doing:
A - So the whole purpose of all of this code is to print a simple message out to the console. If you recall back to the post on the NSLog, we use placeholders to tell the compiler to insert variable values at certain places in the NSLog message. Well, in the event that there are multiple placeholders, how does it know which one to put where? It goes by the order of appearance. So the placeholders above show up in this order: %@, %@, %d, %d, %f. It is now up to us to make sure that the variables following the end of the string message are in the same order: string, string, integer, integer, and double.
B - You recall from earlier posts the fact that often times when we make method calls to a method that has a return type, we can immediately assign the result of that call right into a variable. So it is as if the call in and of itself is actually a variable of the type that it is returning, does that make sense? If you look at the variable part of the NSLog above, you notice that there aren't any variables! That might seems confusing, but as I mentioned, we can treat method calls with a return type the same as if they were a variable of that return type. This allows us to make these method calls, and have their returning values get thrown into the NSLog message without any problem.
C - Here we are executing a simple return statement with a literal number value. This isn't always a good idea, but I am doing it here to show that it is possible to throw a raw number, or string value into the return statement.
D - Here we are declaring a local variable, giving it a value, and then returning the variable instead of the actual value. There is no real difference between these two approaches, the latter is better for humans to read because the name of the local variable lets us get a better idea of the purpose of the number. Whereas if we were to just use a literal number value, we might get confused as to what the number is for.
Can you guess what the output of our NSLog message is going to be to the console? If you run it, you should see the following message in your console:
This is one of the many ways you can make method calls that have return types. It is important to realize that you can either assign the method's return value into a new variable, or else (if it makes sense to) just treat the method call itself like a variable.
I hope you have gotten a taste of how useful and important methods are in programming. We use them all day long, so it is imperative that you are very comfortable with the previous few posts. If you are still having some issues with what is going on, go back through with the debugger and follow along with what is going on!
We're ready to move on now to some different material that will help us do more interesting things with our apps.
Stay tuned!
No comments:
Post a Comment