pensepython.github.io/18-inherit.html at master · PensePython/pensepython.github.io

History

773 lines (734 loc) · 46 KB

Raw

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

157

158

159

160

161

162

163

164

165

166

167

168

169

170

171

172

173

174

175

176

177

178

179

180

181

182

183

184

185

186

187

188

189

190

191

192

193

194

195

196

197

198

199

200

201

202

203

204

205

206

207

208

209

210

211

212

213

214

215

216

217

218

219

220

221

222

223

224

225

226

227

228

229

230

231

232

233

234

235

236

237

238

239

240

241

242

243

244

245

246

247

248

249

250

251

252

253

254

255

256

257

258

259

260

261

262

263

264

265

266

267

268

269

270

271

272

273

274

275

276

277

278

279

280

281

282

283

284

285

286

287

288

289

290

291

292

293

294

295

296

297

298

299

300

301

302

303

304

305

306

307

308

309

310

311

312

313

314

315

316

317

318

319

320

321

322

323

324

325

326

327

328

329

330

331

332

333

334

335

336

337

338

339

340

341

342

343

344

345

346

347

348

349

350

351

352

353

354

355

356

357

358

359

360

361

362

363

364

365

366

367

368

369

370

371

372

373

374

375

376

377

378

379

380

381

382

383

384

385

386

387

388

389

390

391

392

393

394

395

396

397

398

399

400

401

402

403

404

405

406

407

408

409

410

411

412

413

414

415

416

417

418

419

420

421

422

423

424

425

426

427

428

429

430

431

432

433

434

435

436

437

438

439

440

441

442

443

444

445

446

447

448

449

450

451

452

453

454

455

456

457

458

459

460

461

462

463

464

465

466

467

468

469

470

471

472

473

474

475

476

477

478

479

480

481

482

483

484

485

486

487

488

489

490

491

492

493

494

495

496

497

498

499

500

501

502

503

504

505

506

507

508

509

510

511

512

513

514

515

516

517

518

519

520

521

522

523

524

525

526

527

528

529

530

531

532

533

534

535

536

537

538

539

540

541

542

543

544

545

546

547

548

549

550

551

552

553

554

555

556

557

558

559

560

561

562

563

564

565

566

567

568

569

570

571

572

573

574

575

576

577

578

579

580

581

582

583

584

585

586

587

588

589

590

591

592

593

594

595

596

597

598

599

600

601

602

603

604

605

606

607

608

609

610

611

612

613

614

615

616

617

618

619

620

621

622

623

624

625

626

627

628

629

630

631

632

633

634

635

636

637

638

639

640

641

642

643

644

645

646

647

648

649

650

651

652

653

654

655

656

657

658

659

660

661

662

663

664

665

666

667

668

669

670

671

672

673

674

675

676

677

678

679

680

681

682

683

684

685

686

687

688

689

690

691

692

693

694

695

696

697

698

699

700

701

702

703

704

705

706

707

708

709

710

711

712

713

714

715

716

717

718

719

720

721

722

723

724

725

726

727

728

729

730

731

732

733

734

735

736

737

738

739

740

741

742

743

744

745

746

747

748

749

750

751

752

753

754

755

756

757

758

759

760

761

762

763

764

765

766

767

768

769

770

771

772

773

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

<title>Inheritance — Pense Python 2e documentation</title>

var DOCUMENTATION_OPTIONS = {

URL_ROOT: './',

VERSION: '2e',

COLLAPSE_INDEX: false,

FILE_SUFFIX: '.html',

HAS_SOURCE: true

};

</script>

</head>

<h1>Inheritance<a class="headerlink" href="#inheritance" title="Permalink to this headline">¶</a></h1>

The language feature most often associated with object-oriented

programming is inheritance. Inheritance is the ability to define a

new class that is a modified version of an existing class. In this

chapter I demonstrate inheritance using classes that represent playing

cards, decks of cards, and poker hands.

If you don’t play poker, you can read about it at

<a class="reference external" href="http://en.wikipedia.org/wiki/Poker">http://en.wikipedia.org/wiki/Poker</a>, but you don’t have to; I’ll tell you

what you need to know for the exercises.

Code examples from this chapter are available from

<a class="reference external" href="http://thinkpython2.com/code/Card.py">http://thinkpython2.com/code/Card.py</a>.

<h2>Card objects<a class="headerlink" href="#card-objects" title="Permalink to this headline">¶</a></h2>

There are fifty-two cards in a deck, each of which belongs to one of

four suits and one of thirteen ranks. The suits are Spades, Hearts,

Diamonds, and Clubs (in descending order in bridge). The ranks are Ace,

2, 3, 4, 5, 6, 7, 8, 9, 10, Jack, Queen, and King. Depending on the game

that you are playing, an Ace may be higher than King or lower than 2.

If we want to define a new object to represent a playing card, it is

obvious what the attributes should be: rank and suit. It is not as

obvious what type the attributes should be. One possibility is to use

strings containing words like <code class="docutils literal">'Spade'</code> for suits and <code class="docutils literal">'Queen'</code> for

ranks. One problem with this implementation is that it would not be easy

to compare cards to see which had a higher rank or suit.

An alternative is to use integers to encode the ranks and suits. In

this context, “encode” means that we are going to define a mapping

between numbers and suits, or between numbers and ranks. This kind of

encoding is not meant to be a secret (that would be “encryption”).

For example, this table shows the suits and the corresponding integer

codes:

</colgroup>

<tr class="row-odd"><td>Spades</td>

<td>\mapsto</td>

</tr>

<tr class="row-even"><td>Hearts</td>

<td>\mapsto</td>

</tr>

<tr class="row-odd"><td>Diamonds</td>

<td>\mapsto</td>

</tr>

<tr class="row-even"><td>Clubs</td>

<td>\mapsto</td>

</tr>

</tbody>

</table>

This code makes it easy to compare cards; because higher suits map to

higher numbers, we can compare suits by comparing their codes.

The mapping for ranks is fairly obvious; each of the numerical ranks

maps to the corresponding integer, and for face cards:

</colgroup>

<td>\mapsto</td>

</tr>

<tr class="row-even"><td>Queen</td>

<td>\mapsto</td>

</tr>

<td>\mapsto</td>

</tr>

</tbody>

</table>

I am using the \mapsto symbol to make it clear that these

mappings are not part of the Python program. They are part of the

program design, but they don’t appear explicitly in the code.

The class definition for Card looks like this:

<div class="highlight-python"><div class="highlight"><pre>class Card:

"""Represents a standard playing card."""

def __init__(self, suit=0, rank=2):

self.suit = suit

self.rank = rank

</pre></div>

</div>

As usual, the init method takes an optional parameter for each

attribute. The default card is the 2 of Clubs.

To create a Card, you call Card with the suit and rank of the card you

want.

<div class="highlight-python"><div class="highlight"><pre>queen_of_diamonds = Card(1, 12)

</pre></div>

</div>

<h2>Class attributes<a class="headerlink" href="#class-attributes" title="Permalink to this headline">¶</a></h2>

In order to print Card objects in a way that people can easily read, we

need a mapping from the integer codes to the corresponding ranks and

suits. A natural way to do that is with lists of strings. We assign

these lists to class attributes:

<div class="highlight-python"><div class="highlight"><pre># inside class Card:

suit_names = ['Clubs', 'Diamonds', 'Hearts', 'Spades']

rank_names = [None, 'Ace', '2', '3', '4', '5', '6', '7',

'8', '9', '10', 'Jack', 'Queen', 'King']

def __str__(self):

return '%s of %s' % (Card.rank_names[self.rank],

Card.suit_names[self.suit])

</pre></div>

</div>

Variables like <code class="docutils literal">suit_names</code> and <code class="docutils literal">rank_names</code>, which are defined

inside a class but outside of any method, are called class attributes

because they are associated with the class object Card.

This term distinguishes them from variables like suit and rank, which

are called instance attributes because they are associated with a

particular instance.

Both kinds of attribute are accessed using dot notation. For example, in

<code class="docutils literal">__str__</code>, self is a Card object, and self.rank is its rank.

Similarly, Card is a class object, and <code class="docutils literal">Card.rank_names</code> is a list of

strings associated with the class.

Every card has its own suit and rank, but there is only one copy of

<code class="docutils literal">suit_names</code> and <code class="docutils literal">rank_names</code>.

Putting it all together, the expression <code class="docutils literal">Card.rank_names[self.rank]</code>

means “use the attribute rank from the object self as an index into the

list <code class="docutils literal">rank_names</code> from the class Card, and select the appropriate

string.”

The first element of <code class="docutils literal">rank_names</code> is None because there is no card

with rank zero. By including None as a place-keeper, we get a mapping

with the nice property that the index 2 maps to the string <code class="docutils literal">'2'</code>, and

so on. To avoid this tweak, we could have used a dictionary instead of a

list.

With the methods we have so far, we can create and print cards:

<div class="highlight-python"><div class="highlight"><pre>>>> card1 = Card(2, 11)

>>> print(card1)

Jack of Hearts

</pre></div>

</div>

Object diagram.

</div>

Figure [fig.card1] is a diagram of the Card class object and one Card

instance. Card is a class object; its type is type. card1 is an instance

of Card, so its type is Card. To save space, I didn’t draw the contents

of <code class="docutils literal">suit_names</code> and <code class="docutils literal">rank_names</code>.

</div>

<h2>Comparing cards<a class="headerlink" href="#comparing-cards" title="Permalink to this headline">¶</a></h2>

For built-in types, there are relational operators (<, >, ==, etc.) that

compare values and determine when one is greater than, less than, or

equal to another. For programmer-defined types, we can override the

behavior of the built-in operators by providing a method named

<code class="docutils literal">__lt__</code>, which stands for “less than”.

<code class="docutils literal">__lt__</code> takes two parameters, self and other, and True if self is

strictly less than other.

The correct ordering for cards is not obvious. For example, which is

better, the 3 of Clubs or the 2 of Diamonds? One has a higher rank, but

the other has a higher suit. In order to compare cards, you have to

decide whether rank or suit is more important.

The answer might depend on what game you are playing, but to keep things

simple, we’ll make the arbitrary choice that suit is more important, so

all of the Spades outrank all of the Diamonds, and so on.

With that decided, we can write <code class="docutils literal">__lt__</code>:

<div class="highlight-python"><div class="highlight"><pre># inside class Card:

def __lt__(self, other):

# check the suits

if self.suit < other.suit: return True

if self.suit > other.suit: return False

# suits are the same... check ranks

return self.rank < other.rank

</pre></div>

</div>

You can write this more concisely using tuple comparison:

<div class="highlight-python"><div class="highlight"><pre># inside class Card:

def __lt__(self, other):

t1 = self.suit, self.rank

t2 = other.suit, other.rank

return t1 < t2

</pre></div>

</div>

As an exercise, write an <code class="docutils literal">__lt__</code> method for Time objects. You can use

tuple comparison, but you also might consider comparing integers.

</div>

<h2>Decks<a class="headerlink" href="#decks" title="Permalink to this headline">¶</a></h2>

Now that we have Cards, the next step is to define Decks. Since a deck

is made up of cards, it is natural for each Deck to contain a list of

cards as an attribute.

The following is a class definition for Deck. The init method creates

the attribute cards and generates the standard set of fifty-two cards:

<div class="highlight-python"><div class="highlight"><pre>class Deck:

def __init__(self):

self.cards = []

for suit in range(4):

for rank in range(1, 14):

card = Card(suit, rank)

self.cards.append(card)

</pre></div>

</div>

The easiest way to populate the deck is with a nested loop. The outer

loop enumerates the suits from 0 to 3. The inner loop enumerates the

ranks from 1 to 13. Each iteration creates a new Card with the current

suit and rank, and appends it to self.cards.

</div>

<h2>Printing the deck<a class="headerlink" href="#printing-the-deck" title="Permalink to this headline">¶</a></h2>

Here is a <code class="docutils literal">__str__</code> method for Deck:

<div class="highlight-python"><div class="highlight"><pre>#inside class Deck:

def __str__(self):

res = []

for card in self.cards:

res.append(str(card))

return '\n'.join(res)

</pre></div>

</div>

This method demonstrates an efficient way to accumulate a large string:

building a list of strings and then using the string method join. The

built-in function str invokes the <code class="docutils literal">__str__</code> method on each card and

returns the string representation.

Since we invoke join on a newline character, the cards are separated by

newlines. Here’s what the result looks like:

<div class="highlight-python"><div class="highlight"><pre>>>> deck = Deck()

>>> print(deck)

Ace of Clubs

2 of Clubs

3 of Clubs

...

10 of Spades

Jack of Spades

Queen of Spades

King of Spades

</pre></div>

</div>

Even though the result appears on 52 lines, it is one long string that

contains newlines.

</div>

<h2>Add, remove, shuffle and sort<a class="headerlink" href="#add-remove-shuffle-and-sort" title="Permalink to this headline">¶</a></h2>

To deal cards, we would like a method that removes a card from the deck

and returns it. The list method pop provides a convenient way to do

that:

<div class="highlight-python"><div class="highlight"><pre>#inside class Deck:

def pop_card(self):

return self.cards.pop()

</pre></div>

</div>

Since pop removes the last card in the list, we are dealing from the

bottom of the deck.

To add a card, we can use the list method append:

<div class="highlight-python"><div class="highlight"><pre>#inside class Deck:

def add_card(self, card):

self.cards.append(card)

</pre></div>

</div>

A method like this that uses another method without doing much work is

sometimes called a veneer. The metaphor comes from woodworking,

where a veneer is a thin layer of good quality wood glued to the surface

of a cheaper piece of wood to improve the appearance.

In this case <code class="docutils literal">add_card</code> is a “thin” method that expresses a list

operation in terms appropriate for decks. It improves the appearance, or

interface, of the implementation.

As another example, we can write a Deck method named shuffle using the

function shuffle from the random module:

<div class="highlight-python"><div class="highlight"><pre># inside class Deck:

def shuffle(self):

random.shuffle(self.cards)

</pre></div>

</div>

Don’t forget to import random.

As an exercise, write a Deck method named sort that uses the list method

sort to sort the cards in a Deck. sort uses the <code class="docutils literal">__lt__</code> method we

defined to determine the order.

</div>

<h2>Inheritance<a class="headerlink" href="#id1" title="Permalink to this headline">¶</a></h2>

Inheritance is the ability to define a new class that is a modified

version of an existing class. As an example, let’s say we want a class

to represent a “hand”, that is, the cards held by one player. A hand is

similar to a deck: both are made up of a collection of cards, and both

require operations like adding and removing cards.

A hand is also different from a deck; there are operations we want for

hands that don’t make sense for a deck. For example, in poker we might

compare two hands to see which one wins. In bridge, we might compute a

score for a hand in order to make a bid.

This relationship between classes—similar, but different—lends itself to

inheritance. To define a new class that inherits from an existing class,

you put the name of the existing class in parentheses:

<div class="highlight-python"><div class="highlight"><pre>class Hand(Deck):

"""Represents a hand of playing cards."""

</pre></div>

</div>

This definition indicates that Hand inherits from Deck; that means we

can use methods like <code class="docutils literal">pop_card</code> and <code class="docutils literal">add_card</code> for Hands as well as

Decks.

When a new class inherits from an existing one, the existing one is

called the parent and the new class is called the child.

In this example, Hand inherits <code class="docutils literal">__init__</code> from Deck, but it doesn’t

really do what we want: instead of populating the hand with 52 new

cards, the init method for Hands should initialize cards with an empty

list.

If we provide an init method in the Hand class, it overrides the one in

the Deck class:

<div class="highlight-python"><div class="highlight"><pre># inside class Hand:

def __init__(self, label=''):

self.cards = []

self.label = label

</pre></div>

</div>

When you create a Hand, Python invokes this init method, not the one in

Deck.

<div class="highlight-python"><div class="highlight"><pre>>>> hand = Hand('new hand')

>>> hand.cards

[]

>>> hand.label

'new hand'

</pre></div>

</div>

The other methods are inherited from Deck, so we can use <code class="docutils literal">pop_card</code>

and <code class="docutils literal">add_card</code> to deal a card:

<div class="highlight-python"><div class="highlight"><pre>>>> deck = Deck()

>>> card = deck.pop_card()

>>> hand.add_card(card)

>>> print(hand)

King of Spades

</pre></div>

</div>

A natural next step is to encapsulate this code in a method called

<code class="docutils literal">move_cards</code>:

<div class="highlight-python"><div class="highlight"><pre>#inside class Deck:

def move_cards(self, hand, num):

for i in range(num):

hand.add_card(self.pop_card())

</pre></div>

</div>

<code class="docutils literal">move_cards</code> takes two arguments, a Hand object and the number of

cards to deal. It modifies both self and hand, and returns None.

In some games, cards are moved from one hand to another, or from a hand

back to the deck. You can use <code class="docutils literal">move_cards</code> for any of these

operations: self can be either a Deck or a Hand, and hand, despite the

name, can also be a Deck.

Inheritance is a useful feature. Some programs that would be repetitive

without inheritance can be written more elegantly with it. Inheritance

can facilitate code reuse, since you can customize the behavior of

parent classes without having to modify them. In some cases, the

inheritance structure reflects the natural structure of the problem,

which makes the design easier to understand.

On the other hand, inheritance can make programs difficult to read. When

a method is invoked, it is sometimes not clear where to find its

definition. The relevant code may be spread across several modules.

Also, many of the things that can be done using inheritance can be done

as well or better without it.

</div>

<h2>Class diagrams<a class="headerlink" href="#class-diagrams" title="Permalink to this headline">¶</a></h2>

So far we have seen stack diagrams, which show the state of a program,

and object diagrams, which show the attributes of an object and their

values. These diagrams represent a snapshot in the execution of a

program, so they change as the program runs.

They are also highly detailed; for some purposes, too detailed. A class

diagram is a more abstract representation of the structure of a program.

Instead of showing individual objects, it shows classes and the

relationships between them.

There are several kinds of relationship between classes:

<li>Objects in one class might contain references to objects in another

class. For example, each Rectangle contains a reference to a Point,

and each Deck contains references to many Cards. This kind of

relationship is called HAS-A, as in, “a Rectangle has a Point.”</li>

<li>One class might inherit from another. This relationship is called

IS-A, as in, “a Hand is a kind of a Deck.”</li>

<li>One class might depend on another in the sense that objects in one

class take objects in the second class as parameters, or use objects

in the second class as part of a computation. This kind of

relationship is called a dependency.</li>

</ul>

A class diagram is a graphical representation of these

relationships. For example, Figure [fig.class1] shows the relationships

between Card, Deck and Hand.

Class diagram.

</div>

The arrow with a hollow triangle head represents an IS-A relationship;

in this case it indicates that Hand inherits from Deck.

The standard arrow head represents a HAS-A relationship; in this case a

Deck has references to Card objects.

The star () near the arrow head is a multiplicity; it indicates how

many Cards a Deck has. A multiplicity can be a simple number, like 52, a

range, like 5..7 or a star, which indicates that a Deck can have any

number of Cards.

There are no dependencies in this diagram. They would normally be shown

with a dashed arrow. Or if there are a lot of dependencies, they are

sometimes omitted.

A more detailed diagram might show that a Deck actually contains a

list of Cards, but built-in types like list and dict are usually not

included in class diagrams.

</div>

<h2>Debugging<a class="headerlink" href="#debugging" title="Permalink to this headline">¶</a></h2>

Inheritance can make debugging difficult because when you invoke a

method on an object, it might be hard to figure out which method will be

invoked.

Suppose you are writing a function that works with Hand objects. You

would like it to work with all kinds of Hands, like PokerHands,

BridgeHands, etc. If you invoke a method like shuffle, you might get the

one defined in Deck, but if any of the subclasses override this method,

you’ll get that version instead. This behavior is usually a good thing,

but it can be confusing.

Any time you are unsure about the flow of execution through your

program, the simplest solution is to add print statements at the

beginning of the relevant methods. If Deck.shuffle prints a message that

says something like Running Deck.shuffle, then as the program runs it

traces the flow of execution.

As an alternative, you could use this function, which takes an object

and a method name (as a string) and returns the class that provides the

definition of the method:

<div class="highlight-python"><div class="highlight"><pre>def find_defining_class(obj, meth_name):

for ty in type(obj).mro():

if meth_name in ty.__dict__:

return ty

</pre></div>

</div>

Here’s an example:

<div class="highlight-python"><div class="highlight"><pre>>>> hand = Hand()

>>> find_defining_class(hand, 'shuffle')

</pre></div>

</div>

So the shuffle method for this Hand is the one in Deck.

<code class="docutils literal">find_defining_class</code> uses the mro method to get the list of class

objects (types) that will be searched for methods. “MRO” stands for

“method resolution order”, which is the sequence of classes Python

searches to “resolve” a method name.

Here’s a design suggestion: when you override a method, the interface of

the new method should be the same as the old. It should take the same

parameters, return the same type, and obey the same preconditions and

postconditions. If you follow this rule, you will find that any function

designed to work with an instance of a parent class, like a Deck, will

also work with instances of child classes like a Hand and PokerHand.

If you violate this rule, which is called the “Liskov substitution

principle”, your code will collapse like (sorry) a house of cards.

</div>

<h2>Data encapsulation<a class="headerlink" href="#data-encapsulation" title="Permalink to this headline">¶</a></h2>

The previous chapters demonstrate a development plan we might call

“object-oriented design”. We identified objects we needed—like Point,

Rectangle and Time—and defined classes to represent them. In each case

there is an obvious correspondence between the object and some entity in

the real world (or at least a mathematical world).

But sometimes it is less obvious what objects you need and how they

should interact. In that case you need a different development plan. In

the same way that we discovered function interfaces by encapsulation and

generalization, we can discover class interfaces by data

encapsulation.

Markov analysis, from Section [markov], provides a good example. If you

download my code from <a class="reference external" href="http://thinkpython2.com/code/markov.py">http://thinkpython2.com/code/markov.py</a>, you’ll see

that it uses two global variables—<code class="docutils literal">suffix_map</code> and <code class="docutils literal">prefix</code>—that

are read and written from several functions.

<div class="highlight-python"><div class="highlight"><pre>suffix_map = {}

prefix = ()

</pre></div>

</div>

Because these variables are global, we can only run one analysis at a

time. If we read two texts, their prefixes and suffixes would be added

to the same data structures (which makes for some interesting generated

text).

To run multiple analyses, and keep them separate, we can encapsulate the

state of each analysis in an object. Here’s what that looks like:

<div class="highlight-python"><div class="highlight"><pre>class Markov:

def __init__(self):

self.suffix_map = {}

self.prefix = ()

</pre></div>

</div>

Next, we transform the functions into methods. For example, here’s

<code class="docutils literal">process_word</code>:

<div class="highlight-python"><div class="highlight"><pre>def process_word(self, word, order=2):

if len(self.prefix) < order:

self.prefix += (word,)

return

try:

self.suffix_map[self.prefix].append(word)

except KeyError:

# if there is no entry for this prefix, make one

self.suffix_map[self.prefix] = [word]

self.prefix = shift(self.prefix, word)

</pre></div>

</div>

Transforming a program like this—changing the design without changing

the behavior—is another example of refactoring (see

Section [refactoring]).

This example suggests a development plan for designing objects and

methods:

<li>Start by writing functions that read and write global variables (when

necessary).</li>

<li>Once you get the program working, look for associations between

global variables and the functions that use them.</li>

<li>Encapsulate related variables as attributes of an object.</li>

<li>Transform the associated functions into methods of the new class.</li>

</ol>

As an exercise, download my Markov code from

<a class="reference external" href="http://thinkpython2.com/code/markov.py">http://thinkpython2.com/code/markov.py</a>, and follow the steps described

above to encapsulate the global variables as attributes of a new class

called Markov. Solution: <a class="reference external" href="http://thinkpython2.com/code/Markov.py">http://thinkpython2.com/code/Markov.py</a> (note

the capital M).

</div>

<h2>Glossary<a class="headerlink" href="#glossary" title="Permalink to this headline">¶</a></h2>

<dt>codificar (encode)</dt>

<dd>To represent one set of values using another set of values by constructing a mapping between them.</dd>

<dt>atributo de classe (class attribute)</dt>

<dd>An attribute associated with a class object. Class attributes are defined inside a class definition but outside any method.</dd>

<dt>atributo de instância (instance attribute)</dt>

<dd>An attribute associated with an instance of a class.</dd>

<dt>fachada (veneer)</dt>

<dd>A method or function that provides a different interface to another function without doing much computation.</dd>

<dt>herança (inheritance)</dt>

<dd>The ability to define a new class that is a modified version of a previously defined class.</dd>

<dt>classe base (parent class)</dt>

<dd>The class from which a child class inherits.</dd>

<dt>classe derivada (child class)</dt>

<dd>A new class created by inheriting from an existing class; also called a “subclass”.</dd>

<dt>relação É-UM (IS-A relationship)</dt>

<dd>A relationship between a child class and its parent class.</dd>

<dt>relação TEM-UM (HAS-A relationship)</dt>

<dd>A relationship between two classes where instances of one class contain references to instances of the other.</dd>

<dt>dependência (dependency)</dt>

<dd>A relationship between two classes where instances of one class use instances of the other class, but do not store them as attributes.</dd>

<dt>diagrama de classe (class diagram)</dt>

<dd>A diagram that shows the classes in a program and the relationships between them.</dd>

<dt>cardinalidade (multiplicity)</dt>

<dd>A notation in a class diagram that shows, for a HAS-A relationship, how many references there are to instances of another class.</dd>

<dt>encapsulamento de dados (data encapsulation)</dt>

<dd>A program development plan that involves a prototype using global variables and a final version that makes the global variables into instance attributes.</dd>

</dl>

</div>

<h2>Exercises<a class="headerlink" href="#exercises" title="Permalink to this headline">¶</a></h2>

For the following program, draw a UML class diagram that shows these

classes and the relationships among them.

<div class="highlight-python"><div class="highlight"><pre>class PingPongParent:

pass

class Ping(PingPongParent):

def __init__(self, pong):

self.pong = pong

class Pong(PingPongParent):

def __init__(self, pings=None):

if pings is None:

self.pings = []

else:

self.pings = pings

def add_ping(self, ping):

self.pings.append(ping)

pong = Pong()

ping = Ping(pong)

pong.add_ping(ping)

</pre></div>

</div>

Write a Deck method called <code class="docutils literal">deal_hands</code> that takes two parameters, the

number of hands and the number of cards per hand. It should create the

appropriate number of Hand objects, deal the appropriate number of cards

per hand, and return a list of Hands.

[poker]

The following are the possible hands in poker, in increasing order of

value and decreasing order of probability:

<dd>two cards with the same rank</dd>

<dd>two pairs of cards with the same rank</dd>

<dt>three of a kind:</dt>

<dd>three cards with the same rank</dd>

<dt>straight:</dt>

<dd>five cards with ranks in sequence (aces can be high or low, so

Ace-2-3-4-5 is a straight and so is 10-Jack-Queen-King-Ace, but

Queen-King-Ace-2-3 is not.)</dd>

<dt>flush:</dt>

<dd>five cards with the same suit</dd>

<dt>full house:</dt>

<dd>three cards with one rank, two cards with another</dd>

<dd>four cards with the same rank</dd>

<dt>straight flush:</dt>

<dd>five cards in sequence (as defined above) and with the same suit</dd>

</dl>

The goal of these exercises is to estimate the probability of drawing

these various hands.

<li>Download the following files from <a class="reference external" href="http://thinkpython2.com/code">http://thinkpython2.com/code</a>:

<dd>: A complete version of the Card, Deck and Hand classes in this

chapter.

</dd>

<dt>PokerHand.py</dt>

<dd>: An incomplete implementation of a class that represents a poker

hand, and some code that tests it.

</dd>

</dl>

</li>

<li>If you run PokerHand.py, it deals seven 7-card poker hands and checks

to see if any of them contains a flush. Read this code carefully

before you go on.

</li>

<li>Add methods to PokerHand.py named <code class="docutils literal">has_pair</code>, <code class="docutils literal">has_twopair</code>, etc.

that return True or False according to whether or not the hand meets

the relevant criteria. Your code should work correctly for “hands”

that contain any number of cards (although 5 and 7 are the most

common sizes).

</li>

<li>Write a method named classify that figures out the highest-value

classification for a hand and sets the label attribute accordingly.

For example, a 7-card hand might contain a flush and a pair; it

should be labeled “flush”.

</li>

<li>When you are convinced that your classification methods are working,

the next step is to estimate the probabilities of the various hands.

Write a function in PokerHand.py that shuffles a deck of cards,

divides it into hands, classifies the hands, and counts the number of

times various classifications appear.

</li>

<li>Print a table of the classifications and their probabilities. Run

your program with larger and larger numbers of hands until the output

values converge to a reasonable degree of accuracy. Compare your

results to the values at <a class="reference external" href="http://en.wikipedia.org/wiki/Hand_rankings">http://en.wikipedia.org/wiki/Hand_rankings</a>.

</li>

</ol>

Solution: <a class="reference external" href="http://thinkpython2.com/code/PokerHandSoln.py">http://thinkpython2.com/code/PokerHandSoln.py</a>.

</div>

<h3><a href="index.html">Table Of Contents</a></h3>

<ul>

<li><a class="reference internal" href="#">Inheritance</a><ul>

<li><a class="reference internal" href="#card-objects">Card objects</a></li>

<li><a class="reference internal" href="#class-attributes">Class attributes</a></li>

<li><a class="reference internal" href="#comparing-cards">Comparing cards</a></li>

<li><a class="reference internal" href="#decks">Decks</a></li>

<li><a class="reference internal" href="#printing-the-deck">Printing the deck</a></li>

<li><a class="reference internal" href="#add-remove-shuffle-and-sort">Add, remove, shuffle and sort</a></li>

<li><a class="reference internal" href="#id1">Inheritance</a></li>

<li><a class="reference internal" href="#class-diagrams">Class diagrams</a></li>

<li><a class="reference internal" href="#debugging">Debugging</a></li>

<li><a class="reference internal" href="#data-encapsulation">Data encapsulation</a></li>

<li><a class="reference internal" href="#glossary">Glossary</a></li>

<li><a class="reference internal" href="#exercises">Exercises</a></li>

</ul>

</li>

</ul>

<h3>Related Topics</h3>

<ul>

<li><a href="index.html">Documentation overview</a><ul>

<li>Previous: <a href="17-cls-meth.html" title="previous chapter">Classes and methods</a></li>

<li>Next: <a href="19-goodies.html" title="next chapter">The Goodies</a></li>

</ul></li>

</ul>

</div>

<li><a href="_sources/18-inherit.txt"

rel="nofollow">Show Source</a></li>

</ul>

</div>

<h3>Quick search</h3>

</form>

Enter search terms or a module, class or function name.

</div>

</div>

</div>

& <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.6</a>

<a href="_sources/18-inherit.txt"

rel="nofollow">Page source</a>

</div>

</body>

</html>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FilesExpand file tree

18-inherit.html

Latest commit

History

18-inherit.html

File metadata and controls