9780596008673

Packed with attention-grabbing graphics, illustrations, cartoons, and photos "Head First Objects" offers a complete introduction to Object-Oriented programming for experienced programmers new to the methodology and even those new to programming. The book builds knowledge in an engaging style that loads information in the reader's brain in a way that works. The latest research in cognitive science, neurobiology, and educational psychology shows that learning takes a lot more than just text on a page. Combining words and pictures not only helps readers understand a subject, but also to remember it. The book starts with the fundamentals and moves on cover the gamut of object-oriented concepts and design principles.

TERM	PRICE	DUE
SEMESTER	$34.64	Aug 02
QUARTER	$32.91	Jul 22
SHORT TERM	$31.18	Jun 22

Brett McLaughlin is a bestselling and award-winning non-fiction author. His books on computer programming, home theater, and analysis and design have sold in excess of 100,000 copies. He has been writing, editing, and producing technical books for nearly a decade, and is as comfortable in front of a word processor as he is behind a guitar, chasing his two sons and his daughter around the house, or laughing at reruns of Arrested Development with his wife.

Brett spends most of his time these days on cognitive theory, codifying and expanding on the learning principles that shaped the Head First series into a bestselling phenomenon. He's curious about how humans best learn, why Star Wars was so formulaic and still so successful, and is adamant that a good video game is the most effective learning paradigm we have.

Gary Pollice is a self-labeled curmudgeon (that's a crusty, ill- tempered, usually old man) who spent over 35 years in industry trying to figure out what he wanted to be when he grew up. Even though he hasn't grown up yet, he did make the move in 2003 to the hallowed halls of academia where he has been corrupting the minds of the next generation of software developers with radical ideas like, "develop software for your customer, learn how to work as part of a team, design and code quality and elegance and correctness counts, and it's okay to be a nerd as long as you are a great one." Gary is also a co-author of Head First Object-Oriented Analysis and Design. Gary is a Professor of Practice (meaning he had a real job before becoming a professor) at Worcester Polytechnic Institute. He went to WPI because he was so impressed with the WPI graduates that he's worked with over the years. He lives in central Massachusetts with his wife, Vikki, and their two dogs, Aloysius and Ignatius. When not working on geeky things he ... well he's always working on geeky things. You can see what he's up to by visiting his WPI home page at http://web.cs.wpi.edu/~gpollice/. Feel free to drop him a note and complain or cheer about the book.

David West would like to describe himself as sheik geek. Unfortunately no one else would describe him in that way. They would say he is a professional Englishman who likes to talk about software development best practices with the passion and energy of an evangelical preacher. Recently Dave has moved to Ivar Jacobson Consulting, where he runs the Americas and can combine his desire to talk about software development and spread the word on rugby and football, and argue that cricket is more exciting that baseball. Before running the Americas for Ivar Jacobson Consulting, Dave worked for a number of years at Rational Software (now a part of IBM). Dave held many positions at Rational and then IBM, including Product Manager for RUP where he introduced the idea of process plug-ins and agility to RUP. Dave still laments the days when he use to sit in a cube and write software in the city of London. This is where he believes he cut his teeth writing big insurance systems with nothing but a green screen and a process flow chart.

Dave can be contacted at dwest@ivarjacobson.com, and if he is not with customers or drinking warm beer with his friends in Boston, he will email you back.

Who is this book for?

xxiv

We know what you're thinking

xxv

Metacognition

xxvii

Bend your brain into submission

xxix

Read Me

xxx

The Technical Team

xxxii

Acknowledgements

xxxiii

Great Software Begins Here

Rock and roll is forever!

2

(1)

Rick's shiny new application

3

(5)

What's the First thing you'd change?

8

(2)

Great Software is...

10

(3)

Great software in 3 easy steps

13

(5)

Focus on functionality first

18

(5)

Test drive

23

(2)

Looking for problems

25

(1)

Analysis

26

(5)

Apply basic OO principles

31

(5)

Design once, design twice

36

(2)

How easy is it to change your applications?

38

(3)

Encapsulate what varies

41

(2)

Delegation

43

(3)

Great software at last (for now)

46

(3)

OOA&D is about writing great software

49

(1)

Bullet Points

50

(6)

Give Them What They Want

You've got a new programming gig

56

(3)

Test drive

59

(2)

Incorrect usage (sort of)

61

(1)

What is a requirement?

62

(2)

Creating a requirements list

64

(4)

Plan for things going wrong

68

(2)

Alternate paths handle system problems

70

(2)

Introducing use cases

72

(2)

One use case, three parts

74

(4)

Check your requirements against your use cases

78

(7)

Your system must work in the real world

85

(7)

Getting to know the Happy Path

92

(14)

OOA&D Toolbox

106

(6)

I Love You, You're Perfect... Now Change

You're a hero!

112

(1)

You're a goat!

113

(2)

The one constant in software analysis & design

115

(5)

Original path? Alternate path? Who can tell?

120

(2)

Use cases have to make sense to you

122

(2)

Start to finish: a single scenario

124

(2)

Confessions of an Alternate Path

126

(4)

Finishing up the requirements list

130

(8)

Duplicate code is a bad idea

138

(2)

Final test drive

140

(1)

Write your own design principle

141

(1)

OOA&D Toolbox

142

(4)

Taking Your Software into the Real World

One dog, two dog, three dog, four...

146

(1)

Your software has a context

147

(1)

Identify the problem

148

(1)

Plan a solution

149

(7)

A tale of two coders

156

(4)

Delegation Detour

160

(2)

The power of loosely coupled applications

162

(5)

Pay attention to the nouns in your use case

167

(13)

From good analysis to good classes...

180

(2)

Class diagrams dissected

182

(5)

Class diagrams aren't everything

187

(4)

Bullet Points

191

(7)

(Part 1) Nothing Ever Stays the Same

Rick's Guitars is expanding

198

(3)

Abstract classes

201

(5)

Class diagrams dissected (again)

206

(1)

UML Cheat Sheet

207

(6)

Design problem tipoffs

213

(2)

3 steps to great software (revisited)

215

(19)

(part 2) Give Your Software a 30-minute Workout

Back to Rick's search tool

234

(3)

A closer look at the search() method

237

(1)

The benefits of analysis

238

(3)

Classes are about behavior

241

(5)

Death of a design (decision)

246

(1)

Turn bad design decisions into good ones

247

(2)

``Double encapsulation'' in Rick's software

249

(6)

Never be afraid to make mistakes

255

(3)

Rick's flexible application

258

(3)

Test driving well-designed software

261

(4)

How easy is it to change Rick's software?

265

(1)

The Great Ease-of-Change Challenge

266

(3)

A cohesive class does one thing really well

269

(3)

The design/cohesion lifecycle

272

(2)

Great software is ``good enough''

274

(2)

OOA&D Toolbox

276

(4)

``My Name is Art Vandelay... I am an Architect''

Solving big problems

280

(1)

It's all in how you look at the big problem

281

(5)

Requirements and use cases are a good place to start...

286

(1)

Commonality and variability

287

(3)

Figure out the features

290

(2)

The difference between features and requirements

292

(2)

Use cases don't always help you see the big picture

294

(2)

Use case diagrams

296

(5)

The Little Actor

301

(1)

Actors are people, too (well, not always)

302

(5)

Let's do a little domain analysis

307

(2)

Divide and conquer

309

(4)

Don't forget who the customer really is

313

(2)

What's a design pattern?

315

(3)

The power of OOA&D (and a little common sense)

318

(2)

OOA&D Toolbox

320

(4)

Bringing Order to Chaos

Feeling a little overwhelmed?

324

(2)

We need an architecture

326

(3)

Start with functionality

329

(2)

What's architecturally significant?

331

(1)

The three Qs of architecture

332

(6)

Reducing risk

338

(3)

Scenarios help reduce risk

341

(8)

Focus on one feature at a time

349

(2)

Architecture is your design structure

351

(4)

Commonality revisited

355

(6)

Commonality Analysis: the path to flexible software

361

(5)

What does it mean? Ask the customer

366

(5)

Reducing risk helps you write great software

371

(1)

Bullet Points

372

(4)

Originality is Overrated

Design principle roundup

376

(1)

The Open-Closed Principle (OCP)

377

(2)

The OCP, step-by-step

379

(3)

The Don't Repeat Yourself Principle (DRY)

382

(2)

DRY is about one requirement in one place

384

(6)

The Single Responsibility Principle (SRP)

390

(2)

Spotting multiple responsibilities

392

(3)

Going from multiple responsibilities to a single responsibility

395

(5)

The Liskov Substitution Principle (LSP)

400

(1)

Misusing subclassing: a case study in in misuing inheritance

401

(1)

LSP reveals hidden problems with your inheritance structure

402

(1)

Subtypes must be substitutable for their base types

403

(1)

Violating the LSP makes for confusing code

404

(2)

Delegate functionality to another class

406

(2)

Use composition to assemble behaviors from other classes

408

(4)

Aggregation: composition, without the abrupt ending

412

(1)

Aggregation versus composition

413

(1)

Inheritance is just one option

414

(3)

Bullet Points

417

(1)

OOA&D Toolbox

418

(6)

The Software is Still for the Customer

Your toolbox is filling up

424

(2)

You write great software iteratively

426

(1)

Iterating deeper: two basic choices

427

(1)

Feature driven development

428

(1)

Use case driven development

429

(1)

Two approaches to development

430

(4)

Analysis of a feature

434

(3)

Writing test scenarios

437

(3)

Test driven development

440

(2)

Commonality Analysis (redux)

442

(4)

Emphasizing commonality

446

(2)

Emphasizing encapsulation

448

(4)

Match your tests to your design

452

(2)

Test cases dissected...

454

(6)

Prove yourself to the customer

460

(2)

We've been programming by contract

462

(1)

Programming by contract is about trust

463

(1)

Defensive programming

464

(9)

Break your apps into smaller chunks of functionality

473

(2)

Bullet Points

475

(3)

OOA&D Toolbox

478

(6)

Putting It All Together

Developing software, OOA&D style

484

(4)

The Objectville Subway problem

488

(2)

Objectville Subway Map

490

(3)

Feature lists

493

(6)

Use cases reflect usage, features reflect functionality

499

(4)

Now start to iterate

503

(2)

A closer look at representing a subway

505

(9)

To use a Line, or not to use a Line

514

(6)

Points of interest on the Objectville Subway (class)

520

(3)

Protecting your classes

523

(8)

Break time

531

(2)

Back to the requirements phase

533

(2)

Focus on code, then focus on customers

535

(4)

Iteration makes problems easier

539

(5)

What does a route look like?

544

(4)

Check out Objectville for yourself!

548

(3)

Iteration #3, anyone?

551

(4)

The journey's not over...

555

(3)

The Top Ten Topics (we didn't cover)

IS-A and HAS-A

558

(2)

Use case formats

560

(3)

Anti-patterns

563

(1)

CRC cards

564

(2)

Metrics

566

(1)

Sequence diagrams

567

(1)

State diagrams

568

(2)

Unit testing

570

(2)

Coding standards and readable code

572

(2)

Refactoring

574

(3)

Speaking the Language of OO

UML and class diagrams

577

(2)

Inheritance

579

(2)

Polymorphism

581

(1)

Encapsulation

582

(4)

Bullet Points

586

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Amazon no longer offers textbook rentals. We do!

Head First Object-Oriented Analysis and Design

Head First Object-Oriented Analysis and Design

0596008678

Summary

Author Biography

Table of Contents

Supplemental Materials

Write a Review