We've finished up our foundation object, but

rather than move right on to our tableau object, let's see how we can stop

typing out the entire string every time we want to refer to a suit.

To do this, we'll create a string property for each suit and

then use this property in both our deck and game model classes.

And since the suit is a property of the card, let's declare these new properties,

and our card class.

In Java, we would do this by using a static variable.

But in Collin there's no static anything.

Instead, Collin has companion objects.

Check it out.

Let's first add back in the brackets for our class.

Then inside the brackets,

let's declare a companion object by typing, companion object.

And then, adding brackets.

Each class can only have one companion object and

the companion object is basically just a place where we put

anything that would have been static in Java so,

inside this companion object is where will be creating the properties for our suits.

Let's start with the clubs property,

val clubs = Clubs then we'll do the diamonds property.

= Diamonds.

And the hearts property.

And finally, the spades property.

Now that we have our properties,

we can use them to replace the string literals in our game model and our deck.

Let's head over to our game model class and

replace these string literals with the properties we just created.

Card.clubs instead of diamonds.

It will be Card.diamonds.

Card.hearts and Card.spades.

And let's do the same thing for a Deck class.

So instead of Clubs, We'll use Card.clubs.

And Card.diamonds.

Card.hearts.

And Card.spades.

Nice.

It's looking pretty good, right?

But there is one thing I don't like about it, and

that's all these little card dot parts.

This project, and cards in general, are only ever going to have one clubs object.

Wouldn't it be nice if we could omit the class it belongs to?

Maybe, but we can't do that to access a property and

a companion object you need to start with the class it's in.

So instead let's head over to the card class and

see one small step we can take to make it better.

Let's start by cutting out all of our properties from the companion object.

And then, deleting the companion object.

Next, I want you to take a deep breath and

prepare to go where no Java developer has gone before.

Into a world outside of classes, where functions and

properties can exist without the shackles of a class.

Let us boldly go beyond the bounds of our card class,

as we please back in our problem not the citizens of the current class but

as citizens of our entire apps package.

Now, let's jump back to our deck class and

get rid of those card dots once and for all.

And let's do the same thing for our game model class.

And cotland whenever we declare a property or

a function outside of the class, it gets scoped to the entire package.

Meaning we can just use it from anywhere within that package.

It also means that there's nothing special about this card class,

we could declare these properties in the App class instead.

And that would be just fine.

And look, the main function's not part of a class either.

That said, it does make more sense to store these properties in the Card File.

But before we add them back, notice the icon next to our card class.

It's the class icon.

Now, let's cut, and paste our properties back into our card class.

And look at that!

The icon changed to the file icon.

Since card.kt contains more than just the card class

IntelliJ decides to show us the file icon, instead of the class icon.

It's not a big deal, but at least now you know why it's happening.

Being able to declare properties and

functions with package level scope is a huge boon to our development.

It lets us write less code and opens entirely new doors for

how we can structure our projects.

It might take a little getting used to but trust me it's well worth it.

In the next video, we'll pick up where we left off with creating an object

to represent a tableau pile.