When we last checked in,

we were deciding how we can add the items that a diner orders to their TableCheck.

To do that, we said we'd need two things, a way to model the menu item and

then a process to add that menu item to the check.

Let's begin with the first.

So what kind of variables could we use to model a menu item?

Well an NSString would be great for the item's name, like cheeseburger.

But it wouldn't be able to hold the price of the item which would be afloat and

that's important.

Also what if we wanted to add an attribute,

like a bool of comes with fries.

Seems like we'd need a collection to keep all that information bundled together.

The obvious choice would be an NSDictionary since that can hold

key value pairs of different data types.

Now for this very simple example we probably could create

NSDictionary objects for each of our menu items.

But what happens when we want to add some functionality or

property that doesn't conform to NSDictionary?

We might find that really limiting.

So what do we do?

Well, if you read the title of this video you probably know the answer.

We're going to create our own custom class.

So here I am back inside dalesDiner,

the Xcode project that is, anyway we said we want to create a custom class.

So let's make that happen.

File > New > File, and in OS X we can pick

Cocoa Class, we'll be very creative and

we'll call it MenuItem, and we can create it.

Now what kind of things will a menu item contain?

Here in our header, we'll want a name for the item like cheeseburger.

So let's give ourselves an NSString property.

And we can call it, itemName.

Next, we'll want a float for the price.

We can call that itemPrice, and remember floats are primitives.

They don't need a memory directive like strong or weak, so

nonatomic is all we are going to need inside those parentheses.

What else might we want?

Well, what about a bool to tell if it's food or beverage?

Restaurants always want to know how much of their revenue is drink,

since the marginal profit on drinks is so high.

So let's create one.

All right I think we have what we need in our MenuItem class, but

we don't need to worry too much we can always come back here if we decide we want

some additional functionality.

So let's head back to our main.m and

see if we can add some menu items to our table check.

Okay so here we are, and

we can see when we left off we had created a TableCheck called table1.

We had assigned a subtotal, a tip, and we'd marked it as TakeOut.

But we haven't added any menu items.

So our customers aren't gonna be too happy about paying $15 for nothing.

Let's see if we can fix that.

Firstly, we'll need to create a MenuItem object.

Okay, let's do that down here.

We'd start by saying menuItem, hey, I'm not getting the code completion I want.

What's going on?

That's right.

We didn't import it yet.

Let's go over, or rather let's go up and

we can type import MenuItem.

All right, there we go.

Now let's try it again.

See, we're getting our auto complete there.

We'll call our first MenuItem grilledCheese,

and we can say MenuItem alloc.

Great, no errors.

We do get this one warning here.

But that's just saying that the variable is unused, grilledCheese.

We haven't done anything with it yet, and that's fine.

So we could add this to our TableCheck but

this MenuItem variable is just named grilledCheese.

The menu item itself has no values, so let's give it some.

First of all we can give it a name,

we can say, grilledCheese.itemName = Grilled Cheese.

Next we'll probably wanna give it a price.

I think $4.50 is a fair price for

grilledCheese, we can do on the instance of the class called grilledCheese.

We'll say grilledCheese.itemPrice = 4.50.

So just to review we created a MenuItem with the variable

name grilledCheese using alloc and init.

Then after that we set the itemName to grilledCheese and

we did that using the dot syntax here.

And then we set the itemPrice, again using the dot syntax, to 4.50.

If we had wanted to, you could also set it like this,

grilledCheese setValue for

whichever key we'd like to do, but that's not nearly as easy, so we won't do that.

Now just for practice let's create ourselves another menu item.

Let's say MenuItem is gonna be soupDuJour.

And we'll set that equal.

To MenuItem alloc init, and of course that will create our instance for

us and below that we'll set some properties.

So we'll say soupDuJour.itemName = @"Soup

Du Jour" cuz that's what it's called.

For you sticklers out there I believe the d is not capitalized.

What's a fair price for soup?

I think we can probably say, how about $3.25?

Okay.

Now it's worth noting in real life you'd probably have dozens or

hundreds of menu items like this.

So we probably would store these values in a database or p list.

We wouldn't create them right here in the body of our code but

that's way beyond the scope of this video, so we're just doing that here.

In addition we've given ourselves some magic numbers the 4.50, the 3.25.

We're gonna leave them in for now and not spend a lot of time creating other

variables since you know not to leave them hanging around in a real project.

Okay, let's give ourselves a little more space and

let's see if we can add those items to our TableCheck.

We had the foresight to create a mutable array called ItemsOrdered.

So it should be easy to add these items to the array.

Let's just go ahead and do it.

We could say that table1, that's the instance of our table check,

.itemsOrdered.

That's the array, and we want to add an object.

And what do we want to add?

Well let's add a grilled cheese.

Okay, cool.

No errors, no problem.

Let's run it and see what happens.

Okay, let's mouse over table1.

Pop it open.

Okay, $15, 5 for the tip.

Items ordered equals nil.

Just in case we'll look into the NSArray.

No, I don't see any grilled cheese in there.

What is going on?

The array is nil.

Pause the video for a moment and

try to figure out why the mutable array didn't hold our value and it's set to nil.

It's a tough one but it's worth thinking about.

Okay, did you give it some thought?

The reason we couldn't add a value to our NS mutable array

is that we never created the empty array, but wait.

Then why could we assign values to our other properties like the subtotal

and the tip?

Well those properties are primitive types specifically floats and

they don't need to be allocated.

Okay that makes sense, but then how about these strings?

Those are objects too.

We didn't allocate for them.

Well that's right we didn't, but we did use the literal syntax and

that takes care of the ALEC for us.

Okay so we know we left out a step.

How can we fix it?

Well, one way to do it would be for us to alloc the array like this.

We could say that table1.itemsOrdered

equals NSMutableArray, alloc init.

And then we close it off.

We've still got our break point, so let's run it again.

And see if that worked.

Okay if we mouse over table1, we can open it up, and

now we see that our items order does have one object and

it is a Grilled Cheese for $4.50.

A little expensive but it's doable.

Okay, so this works, but it doesn't really feel right.

It seems too manual.

Why should we have to tell each table check to allocate memory for

its itemsOrdered array?

I mean, the most important part of the table check is keeping track of what

the customer orders, right?

It seems like this should be ready to go after we alloc and init our table check.

This is a tough one.

But pause the video for another second and

think about where in our code we could fix this issue for all future table checks.

Well, like I said, this is a tough one.

What you would want to do is customize the init method of the TableCheck class

to automatically alloc the items ordered array.

Now, we haven't written any custom methods.

We haven't even written any methods at all.

But as a sneak peek, let's create one now and talk through it.

Then in our next video, we'll go whole hog on the topic of methods.

So, let's head over to TableCheck.m, and if we didn't

do anything then we could call init on this class like we're currently doing.

It'll automatically use the init method defined inside NSObject

since that's our superclass.

See if we switch to the .h here we see that TableCheck is a subclass of NSObject.

Remember when we subclass an object, it inherits the attributes and

functionality of its superclass, unless we specify otherwise, all right.

Well it's time to specify otherwise, we'll head back to that .m, and

then we'll begin typing out our new init method.

Now let's walk through that code, but again this is just a sneak peek so

we won't dissect absolutely everything.

What we're saying is let's define a method called init that can return any type.

That's what the id means right here.

Init is a method that our superclass already has,

our superclass of course is NSObject.

So we're creating a custom version of it now.

Inside the curly braces, we're creating an instance of TableCheck,

and then we're using the superclasses init method.

Then provided that the self, that is, the instance already exists, we're saying that

itemsOrdered, the NSMutableArray should now be allocated and inited.

Then we're gonna return a copy of self that is the TableCheck instance.

I know that was a mouthful, and

I absolutely don't want you to get bogged down in this syntax.

On the contrary, I just wanted to show this code since it touches on so

many of the different concepts and conventions which need to come together in

order to begin working in an object oriented manner.

We've got our custom class TableCheck inheriting from its superclass NSObject.

Here we're using the superclasses version of init inside our own custom init method.

We do this specifically because we want to allocate

an NSMutableArray called itemsOrdered.

That's very important,

because then it'll be ready to use after we init any instance of TableCheck.

The big headline is, we just changed the class TableCheck, so that every

instance of that class we create will now be improved per our specification.

Specifically, its itemsOrdered array will be alloc-ed and ready to rock.

If we want all orders to be assumed to come with fries right at the start,

we could put code inside our custom init, like this.

Self.comesWithFries = YES.

Now, we're going to get an error here,

because we didn't create a property for that.

But you see what I'm getting at.

That would make sure that when we create any new instance of a class,

that bool would automatically be set to YES.

Okay, let's hop back to our main.

We're going to comment out this line right here where we manually alloced

itemsOrdered and we'll run it again.

We can mouse over our TableCheck and here again we see itemsOrdered 1 object and

it should be a $4.50 Grilled Cheese, very good.

Now just to drive the point home, let's stop the program.

Let's drop a breakpoint in here before we init TableCheck.

We'll put one in down here as well and

then we'll put one in inside our custom init method.

Let's run our code again and see what happens.

Okay our code stops before we can alloc and init,

let's continue and see what happens.

We wind up inside the init method for TableCheck.

So it's going and finding its own init method because we created one.

Had we not created one, it would have just used the NSObject init method.

We continue down here, and we can see that table1.

Has its array, doesn't have any objects yet, but we have alloced and

inited our array.

If we go one more step, we'll now see that

an object has been added, see now we have one object inside itemsOrdered.

But you know while we're here, why don't we get rid of these plugs up here and

actually add to the subtotal using the item prices and menu items were adding.

We could do that down below like this.

Table1.subtotal += grilledCheese.itemPrice

because that's the property that contains the price.

Next, we could say, table1.itemsOrdered

addObject:soupDuJour.

And we can add that price too.

We'll get rid of these breakpoints up top, we don't need those.

And we'll run our code again.

You don't need any of these brackets here.

Now we'll run our code again.

And we can get rid of the breakpoint in our init.

All right here we go.

Now if we look at table1, we can see our subtotal is 7.75,

it's adding as we go that's 3.25 plus 4.50.

But something doesn't smell right.

And I'm not talking about Dale's seafood platter.

These four lines right here, they seem repetitive, and I think we can do better.

So, we figured out how to add properties to the custom classes we've created.

Then we learned how to give those properties values using the dot syntax.

We even got an introduction to customizing or overriding a super classes method.

Heck, we even added instances of one of our custom classes, MenuItem,

to another of our custom classes, TableCheck.

But we ended on sort of a sour note.

We had those four lines where we repeated the same functionality twice.

I feel like we could probably create something a bit more elegant to add

menu items and prices to the table check.

What on earth could we use?

It seems like there should be some method to perform

this type of function in our code.

I know I stumbled on a solution like this once,

in fact it's right on the tip of my tongue.

I know it's.