Afrikaans
Akan
Albanian
Amharic
Arabic
Armenian
Azerbaijani
Basque
Belarusian
Bemba
Bengali
Bihari
Bosnian
Breton
Bulgarian
Cambodian
Catalan
Cebuano
Cherokee
Chichewa
Chinese (Traditional)
Corsican
Croatian
Czech
Danish
Dutch
English
Esperanto
Estonian
Ewe
Faroese
Filipino
Finnish
French
Frisian
Ga
Galician
Georgian
German
Greek
Guarani
Gujarati
Haitian Creole
Hausa
Hawaiian
Hebrew
Hindi
Hmong
Hungarian
Icelandic
Igbo
Indonesian
Interlingua
Irish
Italian
Japanese
Javanese
Kannada
Kazakh
Kinyarwanda
Kirundi
Kongo
Korean
Krio (Sierra Leone)
Kurdish
Kurdish (Soranî)
Kyrgyz
Laothian
Latin
Latvian
Lingala
Lithuanian
Lozi
Luganda
Luo
Luxembourgish
Macedonian
Malagasy
Malay
Malayalam
Maltese
Maori
Marathi
Mauritian Creole
Moldavian
Mongolian
Myanmar (Burmese)
Montenegrin
Nepali
Nigerian Pidgin
Northern Sotho
Norwegian
Norwegian (Nynorsk)
Occitan
Oriya
Oromo
Pashto
Persian
Polish
Portuguese (Brazil)
Portuguese (Portugal)
Punjabi
Quechua
Romanian
Romansh
Runyakitara
Russian
Samoan
Scots Gaelic
Serbian
Serbo-Croatian
Sesotho
Setswana
Seychellois Creole
Shona
Sindhi
Sinhalese
Slovak
Slovenian
Somali
Spanish
Spanish (Latin American)
Sundanese
Swahili
Swedish
Tajik
Tamil
Tatar
Telugu
Thai
Tigrinya
Tonga
Tshiluba
Tumbuka
Turkish
Turkmen
Twi
Uighur
Ukrainian
Urdu
Uzbek
Vietnamese
Welsh
Wolof
Xhosa
Yiddish
Yoruba
Zulu
Now, so far in the course we've been using built-in Ruby methods.
And they've been really handy in the last exercise you used them to print out your players
in four different formats.
And that's been fun and all, but it's probably time to decide on a single way to start the
game for all our players.
In other words, we need some consistency here.
We actually have another issue to address here as well.
When you say we have four players in four different formats, we probably have four different
pieces of code, which means we've got duplication in our code.
Notice that we have four stanzas of code, each printing a player in a slightly different
format.
Now, to make these consistent, we might be inclined to change each stanza.
But what happens when the fifth player comes along?
Or what happens when we want to change the format again?
Well, we're going to end up with a real mess.
And every time we want to make a change, we'll have to make it in multiple places.
One of the basic tenets of good programming is to avoid duplication.
This is sometimes called the dry principle.
But repeat yourself.
So how do we dry up code like this?
Well, we want to be able to put all the formatting code in one place and then call that code
any time we want to print a player.
To do that, we need to write a method.
So in the exercise, we're going to give you a chance to clean up the inconsistency and
duplication in the game.
And to show you how to do that, we're going to look at a similar situation we have with
our movie app.
While you were working on the last exercise, we added some more movies.
Here's where our code stands now.
Right, so we've made the formatting consistent here, but we still have duplication.
Yeah, we have some duplication in our code.
We'd like to clean all this up.
So we're going to write a method to clean it up and put it all in one spot.
OK, so I'm just going to delete all of this code because there's not that much here.
And we're going to remove all this duplication anyway.
And I'm just going to start with a really simple method.
Method starts with the keyword def, and then we give the method name.
We want to print a movie listing, so let's just call this movie listing.
And then it ends with the keyword end.
And then inside of that method, what we want to do is print out a movie.
So I'm going to use our old friend putS.
I'm going to print out movie, movie, and we're just going to stick with Goonies for right
now.
Now defining the method doesn't do anything.
If we try to run this, we don't get any output here.
To call the method, we just call it by its name.
We just call movie listing like that.
Remember, we have an object here.
It's this object that's stored in self, so there is a receiver for this method.
And in a top level program like this, we've seen how that's already arranged.
I can just call it now, and sure enough, we get the movie listing.
Of course, now that we have a method, we could call it any number of times.
So we might want to print this movie listing out, say, three times.
And there we go.
This code actually contains two method calls, one on the method movie listing and the other
on the method putS.
Right.
So we've got a nested method call.
We call the movie listing method, which goes into this method, and then it turns around
and calls putS there.
So we're actually calling two methods.
You're right.
So right now, every time we call the method, it prints the movie listing to the screen.
Right.
And what if we don't want that every time?
What if we want instead it to return a string, then we can evaluate it or do something with
it?
So let's change the method to actually return a string.
Yeah.
So let's just remove this putS from inside of the method.
Now if we run it, well, we get no output because we're calling the method, and it's just returning
a string, but we're not doing anything with it.
So let's say in the first case, we actually do want to print out that movie listing to
the console.
So we put a putS there.
We're going to call the movie listing method.
It's going to return a string and putS takes a string.
So if we run it now, we should get one movie listing.
Now you may have noticed in Ruby, we didn't have to explicitly return something inside
of that method.
What happens is the last expression that's evaluated in the method, the result of that
expression is then returned from the method.
And just to demonstrate this, we've only got one line in this method right now.
If I were to change this to have, oh, I don't know, something like the number 10 as the
last expression then, if I run it now, we actually get 10 printed out to the console
because it's the last expression in the method.
Now it would be nice if this method were more generic and we could print like any movie.
Sure.
Let's pass in that movie name as a parameter.
So at the end of the method definition here, we just pass in a parameter in parentheses
and we'll call the parameter title.
That's going to hold on to the name of the movie we pass in.
And then we've already seen we can substitute in variables to strings.
So let's use the interpolation syntax here again.
We use title.
And just to be a little bit flash, let's just go ahead and capitalize that title name because
we know we can call methods inside of there as well.
Now if we run the program now, we're going to get an error.
It says the wrong number of arguments, 0, 4, 1.
So we need to pass in our actual movie name.
I'm going to drop these two other listings.
We don't actually need those right now.
So to get the same string we had before, let's pass in Goonies.
We can pass it in lowercase because it's going to get capitalized.
And we're right back to our movie listing.
But the cool thing about this now is we can print out different movies, which was kind
of the goal.
So we can have Ghostbusters.
Now we could also store the movie name in a local variable.
Let's say I had a local variable called aTitle.
And we're just going to set that to Goldfinger.
And then I could call putAs movie listing.
And then I could just pass in that variable, aTitle.
So this local variable name does not have to match this parameter name.
What happens is this local variable ends up pointing to the string Goldfinger.
And this title parameter also ends up pointing to Goldfinger.
So you can either do them inline, as we did above, or you can have local variables and
then pass those in as the parameters.
How about printing the movie's rank too?
Yeah, we could make that generic too.
We'll just pass it in as another parameter to the movie listing.
I'll just use a comma to separate the parameters.
And we'll just use rank.
And then inside of our string, we'll say has a rank of rank, just like that.
And then when we call the method, when we're printing out Goonies, we have to pass in a
value for that to fill in that variable.
So let's say Goonies has a rank of 10 and Ghostbusters has a rank of 9, for example.
So if we run it now, we see we have two movie listings.
We've got Goonies has a rank of 10, Ghostbusters has a rank of 9, but it's not printing out
Goldfinger.
We get this error wrong number of arguments.
And that's because we're not passing in rank.
And right now, rank is a required parameter.
So what if we didn't want to pass in a rank for Goldfinger?
Well let's fix that.
So method parameters in Ruby can have default values.
And we do that, we just come up to the parameter in the method definition and then we use the
equal sign and then we give it the default value.
So let's say the default rank for movies is going to be 0.
Now if we do that, we don't have to pass in a rank.
If we run the program again, now we have our Goldfinger movie and it has a default rank
of 0.
So something that's kind of cool is these default parameter values can be derived from
previous parameter values.
We could say something like the rank is equal to the length of the title.
The title is a parameter here and we're just going to derive the rank from that.
So if we run it now, Goldfinger has a rank of 10 because Goldfinger has 10 characters
inside of it.
And we know that if you have a longer title, you have a higher ranked movie.
Yeah, that's true.
You get a better rank for the longer title.
So I'm just going to set this back to 0 just so we have that set back there.
And I'm going to also drop this movie part of the string because we kind of know that
we're printing a movie listing.
And there we've got our three movies.
So we've seen four different method styles here.
Let's recap the syntax.
So here's a simple method that doesn't take any parameters.
To run the method, we call it by name.
But what if we want to pass in a person's name?
Well, we declare that the method takes one parameter and call the method with the person's
name.
We could also assign a default person's name if none is given.
If we don't pass it a name, it prints, howdy, partner.
And then to override the default, we pass in a specific name.
Finally, we could declare that a method takes two parameters, say, name and age.
In this case, both are required.
But we could assign defaults here as well.
So think of a method like a little black box.
It takes some parameters, it does something with them, and then it returns some result.
Now right now, our method simply returns a string.
So let's add a bit more to it.
So let's say we wanted to print the weekday as part of our movie listing here.
So I'm going to define a couple local variables inside of this method to set that up.
So first, I just want the current time.
I'm going to assign that to a local variable current time, like that.
And then I want the weekday part of that.
So I want, like, Monday, Tuesday, Wednesday, and so on.
So I'm going to define that in a variable called today.
I'm going to use current time.
And then I'm going to call this method strf time and pass it in a format, %a.
And all that's going to do is it's going to format the time in a weekday format.
So I'm going to have, like, Monday, for example.
Then inside of the string, I'll go ahead and use that variable.
It has a rank of whatever, and I'll say as of today is the variable name.
So now if I run this, we've got our movie listing, and it's Thursday, so all these movie
listings are good as of today.
So today is a local variable inside of this method, and we said that methods are like
little black boxes.
So if we were to try to access that variable today outside of the method, well, we get
this error, undefined local variable or method today, because today isn't in scope at this
level of the program.
It's only visible or accessible inside of that method.
The same thing is true for current time, for example.
You get the exact same error.
And in fact, if we were to try to print out title, which is a parameter of this method
right here, we run that, we get the same thing, undefined local variable or method title.
So even the parameters or the parameter names, title and rank in this case, aren't accessible
outside of that method.
So again, a method is like a little black box.
So Mike, we have a single method here.
We should show them that methods can call other methods, because all good programs are
composed of many small methods that just do one thing.
So maybe it would be handy if we had a method, maybe call it weekday, that just returns the
weekday name, and we can pull it out of this method.
Yeah, that's a good idea.
And then the movie listing could all, could then turn around and call that weekday method.
And in fact, we've got a couple things going on inside of this movie listing.
We're trying to get the weekday, which we do in the first couple lines, and then we
actually print out the movie listing.
So it's almost doing too much as it is.
So let's take this out.
I'm actually going to cut out this code.
And then above this method, I'll define a method called, oh, you had the name weekday,
which works really well.
And then I'll just paste that code in there.
So all this weekday method does, it gets the current time, and then it formats it in the
weekday format.
And in fact, we don't even need this local variable, because we know that the last expression
evaluated method is going to be automatically returned.
So we're going to return the weekday here.
Then inside of this method, we could go back to assigning, today will just be whatever
the weekday method returns.
I've got to remove this, or we're going to get this error down here.
So if I run that, we get the same thing.
It's as of Thursday.
But this local variable, I mean, we're really not doing much with this.
So I can actually, where we use today right here, instead, let's just call the method
weekday, which is going to return a string for us, and it'll get substituted right in
there.
And then we can drop that local variable altogether.
Just a quick check, and the movie listing is the same as it was before.
Now suppose we change our mind.
What if we want the weekday printed first?
Well here's the benefit of having all this code inside of one method.
We only have to make the change in one place.
So we're just going to move this around.
We don't want the weekday at the end of this string.
We just want to put it at the beginning.
I'll put a colon there.
And then we want to upcase the weekday, like that.
So we just change that one string in that method movie listing.
If we run it now, we've got exactly what we want, the weekday printed at the beginning
and all uppercased.
And that change rippled through for all of the movie listings.
Now it's important to note here that the method call itself doesn't change.
We just call movie listing passing in the name of the movie and the rank.
So from the outside, it's all the same, which means the changes that we made are isolated
just to the internals of the movie listing method.
So I don't know about you, but that's pretty cool.
We started with a mess, lots of duplication and consistency.
We wrote two methods, and now we have something that's really clean and elegant.
So now it's your turn.
In the exercise, you're going to write your own method for consistently starting the game
for your players.
You'll also get a chance to practice with a few built-in Ruby methods.
And in the next section, we'll take things a step further.
You could write programs composed of nothing but a bunch of small methods, but you'd be
missing a really key aspect of object-oriented programming.
So in the next section, we'll look at how to define classes that help us then create
objects.
So we'll see you then.
Bye.
Can't find what you're looking for?
Get subtitles in any language from opensubtitles.com, and translate them here.