Original subtitles

In the last section, we started working through our dart program design flow here, that's hopefully

going to give us a reasonable design for our application.

We went through step one and we ended up saying that we're going to have two classes inside of application

one to represent a single card and then one to represent a collection of cards.

We're not going to move on to step two, where we're going to think about the different properties or

fields that are going to belong to each of these classes.

So we need to begin by thinking about the different pieces of data that should be tied to each of the

things that exist inside of rap.

Now, I'm going to go back over to my diagram of our deck of cards over here.

And we'll first begin by thinking about the different fields or properties that should belong to an

individual cart.

So specifically the card class.

So I'm going to drag a card down here just so we can study it in great detail by itself.

So as I look at this individual card, I can really only think of two properties that should belong

to this thing.

The first is the rank of the card, in this case, Ace.

So the rank of a card would be like ACE two, three, four, five, six, seven, all the way up to

ten, Jack King, Queen and so on.

The other property that I think this should have should be the suit as well.

So is this a card of diamonds or of spades?

Of hearts of clubs?

So in total, I think that our card class will have two properties associated with it, the rank right

here in the suit right here.

The other thing I want to mention is I think both of these fields will be of type string.

I think that makes a lot of sense.

In the case of the suit right here, we should store a string of like literally diamonds.

In the case of the ring, you could definitely make a case for saying that we should store that as an

integer where one would represent an ace and then maybe 11 would be Jack Queen would be 12.

Am I doing that right?

Yes, King would be 13.

But I think that in this case, just using a string to indicate the rank makes a lot of sense as well,

because the end goal here is going to be us wanting to actually print out some information about these

cards in would definitely make a lot more sense to display that as a simple as queen king rather than

having to deal with some integers.

OK, so I think that takes care of the individual cards.

Now, the other class we have to think about is the collection of fields or the different properties

that's going to belong to the deck class.

Remember that we had just said that an individual card doesn't make a lot of sense by itself.

It's only when we combine together a bunch of cards into a deck that we start getting a interesting

application and we can actually make a game out of it.

So I think that for the properties that belongs to the deck, we'll probably just have one single property

or one single field.

And that will be a list of cards exactly as you see right here.

So every deck instance inside of our application will have a collection of card instances somehow associated

with it.

OK, so let's take these kind of decisions about our design, we're going to go back over to our design

flow here.

So we just did this thing right here.

We thought about the different pieces of data that should be attached to each thing.

We're now going to want to create a field on each class that's going to hold that type of data.

And one other thing I want to look at very quickly is just a summary of what we're deciding at this

point.

So for the card class, we're going to have a suit of type string and a rank of type type string.

Then for the DECLASSE, we're going to have a cards property, so this card's property right here is

going to reflect all the different cards that belong to this particular deck.

And it's going to be of type list of cards.

I want to very quickly zoom in on this, because the syntax I used here is actually somewhat important

because I'm going to blow up the text here.

Let's do thirty six.

There we go.

So the syntax I used here to indicate this type is something that we're going to see inside of our dark

code as well.

This means that the cards property over here should be a value of type list that contains only instances

of cards.

So that kind of little Brace's right here, brackets that you see right here means to say that inside

this list, we're just going to have values of Type Kaat.

The other thing I want to mention is what this list right thing right here is as well.

So in dirt, we have a kind of but we don't call them arrays.

Instead, we call them lists.

So when we say list of cards right here, you can also think of this as being like an array of cards,

same type of thing.

But to actually list that out or to actually designate that we would write list and then card inside

of the braces.

OK, so let's now flip back over to pad and we're going to add on these fields to our program.

So we'll go back over to D'Arte Pad, here we go, and then remember the syntax that we use for adding

fields to a class, we write out the type that we want to add to it.

So in this case, I'm going to add a string and then the name of the field.

So for the card, we're going to deal with a suit and we're going to have a string of Reinke as well.

Then for the deck, we're going to do the same thing.

Now, in this case, we want to say that we're going to have a type of list with cards inside of that,

so to indicate that type on our class right here, we can write out list card and then cards.

So just the same as what we did right here where we put down the name of or the type of the property

and then the name of the property.

We did the exact same thing up here as well.

So the name of the property is going to be cards and it's going to be of type list containing nothing

but cards.

OK, so we just got through step two of our design flow here.

Let's come back to the next section and we're going to start thinking about adding methods to represent

each of these classes.

So quick break and I'll see you in just a minute.