Classes for Blackjack

Loading...

From the course by Rice University

An Introduction to Interactive Programming in Python (Part 2)

724 ratings

Rice University

An Introduction to Interactive Programming in Python (Part 2)

724 ratings

Course 2 of 7 in the Specialization Fundamentals of Computing

This two-part course is designed to help students with very little or no computing background learn the basics of building simple interactive applications. Our language of choice, Python, is an easy-to learn, high-level computer language that is used in many of the computational courses offered on Coursera. To make learning Python easy, we have developed a new browser-based programming environment that makes developing interactive applications in Python simple. These applications will involve windows whose contents are graphical and respond to buttons, the keyboard and the mouse. In part 2 of this course, we will introduce more elements of programming (such as list, dictionaries, and loops) and then use these elements to create games such as Blackjack. Part 1 of this class will culminate in building a version of the classic arcade game "Asteroids". Upon completing this course, you will be able to write small, but interesting Python programs. The next course in the specialization will begin to introduce a more principled approach to writing programs and solving computational problems that will allow you to write larger and more complex programs.

From the lesson

Week 6 - Classes and object-oriented programming

Learn the basics of object-oriented programming in Python using classes, work with tiled images

Object-oriented Programming - 19:34

Object-oriented Programming - 28:43

Working with Objects13:24

Classes for Blackjack11:28

Meet the Instructors

Joe Warren
Professor
Computer Science
Scott Rixner
Professor
Computer Science
John Greiner
Lecturer
Department of Computer Science
Stephen Wong
Lecturer
Computer Science

[MUSIC]

Today we're going to talk about the game of Blackjack.

I'm going to actually show you the rules of Blackjack, and

then we're going to talk about how you would take a game like Blackjack and

turn it into an object oriebted program.

Specifically we're going to look at the different types that you would need to

implement and think about why you would want to implement those types.

Now I want to stress, there's no perfect way of doing this.

Like all programming, it's an art not a science.

So you have to think about the design decisions that you're going to make and

because of this we're going to actually show you why we're picking things.

And so I'm going to tell you why, and in fact, Joe is also going to tell you why.

So hopefully by getting the different perspectives and

seeing one way of designing this program,

you're going to get some insight in how we think about object oriented programs.

Now, first, you have to understand the rules of Blackjack and the game of

Blackjack before we can actually discuss how you're going to implement Blackjack.

So, let's play some Blackjack.

>> Okay, welcome to class.

In week six,

we're going to build a computer implementation of the card game Blackjack.

So Blackjack is a gambling game that's played in Las Vegas.

It uses a standard deck of cards,

or a non-standard deck of cards as we have here with the ones that John provided us.

It's a game where a player plays against a dealer.

The dealer usually represents the casino.

The object of the game is to get a hand of cards

whose value sums up to as close to 21 without going over.

So let's just play a hand here and

we'll kind of go through the mechanics of the game.

So what I'm going to do is I'm going to deal out a card to Scott,

and I'm going to deal out a card face down to me, I'm going to deal out another card

to Scott, face up, I'm going to deal another card to me face up.

And the way the game works is Scott gets to go first, and he has two options,

he can either stand or hit.

Hitting requires me to give him another card.

The cards have values.

Face cards have value ten, numerical cards have their numerical value.

And then aces have a special value, they can be chosen to either be one or 11,

the player's option.

So at this point, Scott's gotta finish drawing all of his cards hitting, and

he can stand at any point.

If he goes over 21, he busts and immediately loses the hand.

Then at that point I'll go through and I play my hand and

as dealer I have no choice in how I play it.

I always hit if I have a value less than 17,

and I always stand if I have a value greater than 17.

So I think at this point we're ready to go ahead, so Scott?

>> So if I was really playing this is 11 plus seven, 18, I would probably stand,

but just to demonstrate here I'll hit.

And I have 21, so I'm going to stay.

>> [LAUGH] Why aren't you in Las Vegas right now?

So I'm going to turn my card over, and I have a 14, lucky me, so

let's see I'm going to have to get a seven or automatically lose the hand.

So I have a queen so my hand now is 14 plus ten is 24 so

I'm busted, so Scott wins.

>> Where's my money, Joe?

>> Man, we forgot to set the bet again.

[LAUGH] >> [LAUGH]

>> So those are the rules of Blackjack.

We'll come back in a little while and we'll actually play a game for

some higher stakes and set a very nice deck.

>> So, you just saw a game of Blackjack, and

hopefully now you have a feel for the rules.

I also probably have a little bit of credibility, right?

I now won a game of Blackjack, I want to point that out yet again.

And I also want to point out one more thing before we get started here,

notice how I won and Joe didn't pay up.

I want you to keep that in mind as you watch some future videos.

Anyway, so how do we implement Blackjack?

We're going to implement this as an object oriented program.

And the first part of the design process for

any object oriented program is to think about what new types I'm going to need.

So what do I need to implement the game of Blackjack?

Well, I'm going to argue that I need a card of some sort.

I need a hand to represent to both the dealer's hand and the player's hand.

And I need a deck of cards.

And I think this is pretty much all that we need, right?

These are the physical objects that occur in the game of Blackjack, and

so they're going to have analogs inside of our program.

So let's talk about what these types actually are.

So what's a card?

Well, a card can be represented as a rank and

a suit, so the ace of spades, all right.

And you probably also want an image associated with a card.

That's what I'm going to draw on the screen when I actually have that card.

All right, so that's all there is to a card really.

Hand, what is a hand?

Well, I'd argue that a hand is simply a collection of cards.

And what is a deck?

Well, a deck is also a collection of cards.

Now, if I look at these data types I might think, well,

there's really only two types, right.

There's a thing that's a rank and a suit and an image.

And then there's a thing that's a collection of cards.

But this is not all there is to defining a type.

A type is both the data that is encapsulated inside that type and

the behaviors that you can perform on that data.

So what can I do with a card?

I can't really do much with a card.

Maybe I could rip the card.

Of course I'd probably get thrown out of the casino if I go around ripping cards.

So really probably only behaviors of a card is I can look at the rank,

I can look at the suit, and I can draw the image.

So it's not that interesting.

What about a hand, what can I do with a hand?

Well, a hand has more interesting behaviors.

I can perhaps hit, right, add a card to the hand.

I could score the hand, figure out what it's worth.

Right, maybe it's worth 21 and I know that I don't need to hit anymore.

Okay, so I need these behaviors, at least.

What about a deck, what can I do with a deck?

Well, I would argue that you can shuffle a deck.

You can deal a card, right, when the player hits or

when you deal in the beginning.

Okay, so now it becomes a little more obvious that there are three different

types here.

I have the card, which I think we've discussed, and then I have a hand and

a deck, both of which are collections of cards,

but both of which have different behaviors.

It doesn't make sense to shuffle a hand or to deal a hand.

And it doesn't make sense to hit the deck or to score the deck.

So I have independent behaviors.

With that, we have three different types that we're going to want to implement for

our Blackjack card game.

They each have different behaviors associated with them.

And so now we're well on our way to designing our Blackjack card game.

>> Well, Scott's walked you through an introduction to the classes for Blackjack.

So what I'd like to do is provide a little perspective as somebody who's

not as an experienced a programmer in terms of object oriented design, to give

you my insight as the rationale behind why we should learn more about OO design.

So I've programmed for a long time.

I've been a programmer for 30 years in C and C#, and a lot of mathematics.

But one of the things about the way I build code is I typically build code

for myself.

I might work with another student.

So, the things and the practices that I follow as a programmer

are not necessarily those that are optimal for working in larger projects.

So what I'm going to do is I'm going to talk a little bit about my experiences

in building the Blackjack project.

And some of the discussions that Scott and

I had concerning how to design an appropriate class structure for Blackjack.

About three months ago as Scott got CodeSkuptor online I sat down and

started implementing Blackjack.

And so my first implementations were short and sweet.

My goal was to keep the number of lines small and have it produce a nice game.

Scott's been looking over my code,

thinking about it from the OO's point of view.

And he's noted that some of the design decisions that I made in terms of how I

set up classes in here, probably weren't optimal.

But what does it mean for them not to be optimal?

In OO design, one of the primary objectives is to facilitate code reuse.

If you build your OO design correctly, you can take the code that you built,

you can pull it out and use it in some other project.

So, for example in Blackjack, I built the hand class, I built the card class.

Now, the card class was, I had a rank and a suit, but I also included a value field.

And Scott pointed out, well, cards really don't have a value field,

they don't have a value from one to 11.

Now if you want to build a card class that's going to be able to be used in

other card games, you should really not put that in there.

For example, I want to use it in poker, well, poker doesn't have a value.

So he suggested that I pull that value computation back into a hand class and

think of it as a hand class for Blackjack, a Blackjack hand.

Now that's the place where I can place computations about the value of the hand.

I also implemented a deck as a list of cards, and [INAUDIBLE] that shuffled them,

and dealt them out, things like that.

And again, Scott pointed out that probably a better design decision there would to

build a deck class that would create decks of cards, and have methods for

things like shuffle and deal, or things like that,

that allow you to abstractly interact with the class.

That would allow you to use these methods, again,

this has something like a poker game.

In fact, this whole idea about abtraction, what you do is you separate how

the object is implemented versus how you interact with it, the methods.

It's kind of a nice idea, it allows you when you're building your code

to hide the details that other might not need to know.

How I implement a deck, well it's not so

important as long as I have a correct class submit that's for you to work with.

I can just not even tell you how I implemented the deck of cards.

So those are a couple of observations about how

object oriented design should work.

So, we've talked a lot about Blackjack now and how you might build an object oriented

version, or rather how you may design an object oriented version, of the game.

I just wanted to briefly show you some code.

We're going to walk over this again when we do the mini project runthrough, but

just for now to finish up this video.

Here's my hand class, here's my deck class, so

you can see I have class hand, and then I have a bunch of methods.

I have an initalizer I can turn it into a string.

I could add a card to a hand.

I could get the value of a hand.

I could check if the hand is busted if I have over 21.

And I can actually draw it on the canvas.

Similarly I have a deck.

I initialize, I could shuffle, I can deal And I need a third class of card okay.

So I think this should be straightforward after having seen the lectures on object

oriented programming.

Then we talked about the three different classes that you might want, and

I just wanted to show you, hey, here's what a piece of code might look like.

Again we're going to spend more time on this when we describe the mini project.

Explore our Catalog

Join for free and get personalized recommendations, updates and offers.

Coursera provides universal access to the world’s best education, partnering with top universities and organizations to offer courses online.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play