In our last video we learned how to use an if statement

to create a two pronged fork in the road.

In our case we wanted to decide whether or

not to give a senior discount to our theater customers based on their age.

However, we just found out that we also need to give a discount for

all the customers attending the first showing of each day,

which is often called the matinee.

Specifically, all customers regardless of age should only pay $4 for the matinee.

Okay, here we are back inside our box office project.

Let's incorporate that new matinee discount.

First of all, let's create a bool so we know if it's a matinee or not.

Next, let's add a matinee price.

We can add it to our business rules up here, too.

Also, I see that our variable here, discount price.

Now it's too vague.

Which discount are we talking about?

Let's change that variable name to something more precise and descriptive,

like senior price.

Hm, oh.

I see red.

Quick!

Quick!

Why do we get red?

That's right.

It's because we changed our variable name up here, so X code has no idea what to

do with the discounted price, because we never declared it.

Now I could simply type in, senior price, over here to get rid of the warning, and

that would work, but just for fun, let me show you another way.

Let's change our discount price variable name back to disc price.

Then we right-click, select Refactor, rename.

Then we enter our new name for the variable, which is senior price.

Now this wonderful window shows up,

showing everywhere in our project where the variable might show up.

Now for our tiny example this isn't all that impressive.

But in a real app a variable could show up dozens or

hundreds of times possibly in dozens of different files.

In that case, this is an extremely useful tool.

By the way, if you don't know already, refactoring code is when you improve

the internal workings of your code without changing the external behavior.

It's something programmers do all the time, and

is essential to writing good code.

Much like writing a song or a novel, folks don't usually get it

just right the first time around, and it gets better with editing.

Okay.

So now that we have this third price, it seems like, instead of a simple

two-pronged fork in the road, we would like a way to offer three choices.

The way we do this is with an else if.

An else if may sound a lot like an if, but it's actually quite different.

To illustrate the difference,

let's first try to get the job done using just a series of ifs.

For that,

we might try adding another if statement after we ask about the customer's age.

Specifically, we would add an if with the condition

if is matinee then assign the matinee price.

Now at first pass this might seem like it would work and it would for

some cases but what happens when a 70 year old shows up for an evening movie?

The way our code works they would satisfy this condition and

their price would be set to senior price.

Then we would test the next condition.

Is it a matinee?

No. And that would cause us to skip

this block of code here, and hop in here.

And that would not be good.

Because then it would charge them the regular price of $10.

The fix for that issue is using else if.

Let's delete all of our current logic and recreate it from scratch.

It'll just take a minute.

So first let's check if the matinee, since that's the lowest price we offer.

If this matinee equals yes, we'll set the customer price equal to the matinee price.

If isMatinee custPrice = matPrice.

Next we'll want to say only if the last condition was not met

here's another condition to test.

Specifically is the customer age greater than or equal to the discount age?

So we'll say else if

Lastly we can say that if neither of the conditions above were met then

assign the regular price to the customer price.

You see using that else if effectively changed what the last else

down here really does to our flow.

What it does now is only catch cases where none of the prior conditions were met.

Had we just used an if, it would catch any cases where the customer was under 60,

even if it had satisfied the matinee condition.

To demonstrate how this is actually working,

rather than simply what answer we get at the end,

I'll add a new break point up here, and we'll add one down at the end.

And we'll see how it executes.

I'm also gonna set our customer age to 75 and our isMatinee to Yes.

Okay, let's run it.

All right, we've stopped right here at the first break point.

Now, I wanna step, line by line, through the code we're executing.

Now, just to be clear, we won't be stepping through all the code we wrote,

just what we're actually executing.

To do that, we use this arrow right here.

By the way, this is most certainly not a full lesson in debugging, but

I wanted to use this tool to illustrate our flow.

When I click this arrow we'll evaluate the isMatinee condition.

Okay you'll see that after checking that condition

we wound up inside of our first curly braces where we assign the matinee price.

Great that's just what we wanted.

Now let's see what happens when we click the down arrow again.

Well one click just gets us to the curly brace and

then the next click well that took us all the way to our last break point.

We skipped everything else.

If we peek right here,

we'll see that our customer price is equal to $4, the matinee price.

We hit our initial clause where we assigned the matinee price, and

then we skipped the rest.

Let's try making it a non-matinee and then we'll see what happens.

We run again, and of course we stop at our first break point.

Let's step through.

Huh?

We skipped our first section since the first condition was not met.

Now, when I tap the arrow again, we'll evaluate that condition.

The customer age, which was 75, is greater than the minimum age, so

we wind up inside this curly brace where we're gonna assign the customer

the senior price to the customer price.

Click again.

We get to the closing curly brace, and then once more, we go

all the way to our final break point, where we skip this final else clause.

We mouse over the customer price and

we see we've got the correct senior price of $5.

Let's try one more case, setting the age to something lower, like 15.

We'll run again.

Okay, we've stopped at our first break point.

Step through, we're gonna evaluate is the customer age greater than or

equal to the minimum age?

It's not.

So we wind up here in our else clause

where we're gonna assign the regular price of $10.

For those keeping track at home, we've just tried

three of the four possible combinations of age ranges and isMatinee.

We didn't yet try a person under the age of 60 who is attending a matinee.

Now I won't spend time doing that now but

you'd certainly wanna do that in the real world.

Also, this is a good example of why we usually implement something

called a unit test.

Unit testing is a way to create persistent tests for the code we write so

we know that it can properly handle all the possible values you might throw at it.

For example, what happens if you,

the developer, change some of the inner workings of your code?

Unit testing is the accepted way to formally create, perform, and

reuse those types of tests for individual parts of your code.

They make sure that they function as you think they do and stay that way.

Keep plugging along with iOS, and before too long,

you'll find yourself needing XCTest, which is Xcode's unit testing feature.

But don't worry we definitely aren't there yet.

If you're just dying to learn more about unit testing

I've included some links below about xci test and about unit testing in general.