Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D


"Head First Object Oriented Analysis and Design is a refreshing look at subject of OOAD. What sets this book apart is its focus on learning. The authors have made the content of OOAD accessible, usable for the practitioner."

Ivar Jacobson, Ivar Jacobson Consulting

"I just finished reading HF OOA&D and I loved it! The thing I liked most about this book was its focus on why we do OOA&D-to write great software!"

Kyle Brown, Distinguished Engineer, IBM

"Hidden behind the ...

See more details below
BN.com price
(Save 31%)$59.99 List Price

Pick Up In Store

Reserve and pick up in 60 minutes at your local store

Other sellers (Paperback)
  • All (25) from $15.29   
  • New (9) from $33.54   
  • Used (16) from $15.29   
Head First Object-Oriented Analysis and Design: A Brain Friendly Guide to OOA&D

Available on NOOK devices and apps  
  • NOOK Devices
  • Samsung Galaxy Tab 4 NOOK 7.0
  • Samsung Galaxy Tab 4 NOOK 10.1
  • NOOK HD Tablet
  • NOOK HD+ Tablet
  • NOOK eReaders
  • NOOK Color
  • NOOK Tablet
  • Tablet/Phone
  • NOOK for Windows 8 Tablet
  • NOOK for iOS
  • NOOK for Android
  • NOOK Kids for iPad
  • PC/Mac
  • NOOK for Windows 8
  • NOOK for PC
  • NOOK for Mac
  • NOOK for Web

Want a NOOK? Explore Now

NOOK Book (eBook)
BN.com price
(Save 42%)$50.99 List Price


"Head First Object Oriented Analysis and Design is a refreshing look at subject of OOAD. What sets this book apart is its focus on learning. The authors have made the content of OOAD accessible, usable for the practitioner."

Ivar Jacobson, Ivar Jacobson Consulting

"I just finished reading HF OOA&D and I loved it! The thing I liked most about this book was its focus on why we do OOA&D-to write great software!"

Kyle Brown, Distinguished Engineer, IBM

"Hidden behind the funny pictures and crazy fonts is a serious, intelligent, extremely well-crafted presentation of OO Analysis and Design. As I read the book, I felt like I was looking over the shoulder of an expert designer who was explaining to me what issues were important at each step, and why."

Edward Sciore,Associate Professor, Computer Science Department, Boston College

Tired of reading Object Oriented Analysis and Design books that only makes sense after you're an expert? You've heard OOA&D can help you write great software every time-software that makes your boss happy, your customers satisfied and gives you more time to do what makes you happy.

But how?

Head First Object-Oriented Analysis & Design shows you how to analyze, design, and write serious object-oriented software: software that's easy to reuse, maintain, and extend; software that doesn't hurt your head; software that lets you add new features without breaking the old ones. Inside you will learn how to:

  • Use OO principles like encapsulation and delegation to build applications that are flexible
  • Apply the Open-Closed Principle (OCP) and the Single Responsibility Principle (SRP) to promote reuse of your code
  • Leverage the power of design patterns to solve your problems more efficiently
  • Use UML, use cases, and diagrams to ensure that all stakeholders arecommunicating clearly to help you deliver the right software that meets everyone's needs.

By exploiting how your brain works, Head First Object-Oriented Analysis & Design compresses the time it takes to learn and retain complex information. Expect to have fun, expect to learn, expect to be writing great software consistently by the time you're finished reading this!

Packed with attention-grabbing graphics, illustrations, cartoons, and photos, this unique book builds knowledge in an engaging style that loads information in the reader's brain in a way that works.

Read More Show Less

Product Details

  • ISBN-13: 9780596008673
  • Publisher: O'Reilly Media, Incorporated
  • Publication date: 11/1/2006
  • Series: Head First Series
  • Edition number: 1
  • Pages: 636
  • Sales rank: 498,675
  • Product dimensions: 8.00 (w) x 9.25 (h) x 1.38 (d)

Meet the Author

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.

Dave 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.

Read More Show Less

Table of Contents

Praise for Head First OOA&D;
Praise for other Head First books by the authors;
Praise for other Head First Books;
How to use this Book: Intro;
Who is this book for?;
Who should probably back away from this book?;
We know what you’re thinking;
And we know what your brain is thinking;
Metacognition: thinking about thinking;
Here’s what WE did;
Here’s what YOU can do to bend your brain into submission;
Read Me;
The Technical Team;
Special thanks;
Chapter 1: Well-Designed Apps Rock: Great Software Begins Here;
1.1 Rock and roll is forever!;
1.2 Rick’s shiny new application...;
1.3 Here what the code for Guitar.java looks like;
1.4 And Inventory.java...;
1.5 But then Rick started losing customers...;
1.6 What’s the FIRST thing you’d change?;
1.7 Great software is... more than just one thing;
1.8 Great software in 3 easy steps;
1.9 Remember Rick? Remember his lost customers?;
1.10 So let’s apply our 3 steps;
1.11 Ditching String comparisons;
1.12 Rick’s customers want choices!;
1.13 Test drive;
1.14 Back to our steps;
1.15 Looking for problems;
1.16 Analyze the search() method;
1.17 Now update your own code;
1.18 Update the Inventory class;
1.19 Getting ready for another test drive;
1.20 Getting back to Rick’s app...;
1.21 Design once, design twice;
1.22 Let’s make sure Inventory.java is (really) well-designed;
1.23 One last test drive (and an app ready for reuse);
1.24 What we did;
1.25 Remember this poor guy?;
1.26 OOA&D is about writing great software, not doing a bunch of paperwork!;
Chapter 2: Gathering Requirements: Give Them What They Want;
2.1 You’ve got a new programming gig;
2.2 Todd and Gina: your first customer;
2.3 Let’s start with the dog door;
2.4 Test drive;
2.5 But when Gina tried it...;
2.6 Listen to the customer;
2.7 Creating a requirements list;
2.8 What does the dog door really need to do?;
2.9 Plan for things going wrong;
2.10 Alternate paths handle system problems;
2.11 (Re) introducing use cases;
2.12 One use case, three parts;
2.13 Checking your requirements against your use cases;
2.14 Is anything missing?;
2.15 So now can we write some code?;
2.16 Automatically closing the door;
2.17 We need a new simulator!;
2.18 Test drive, version 2.0;
2.19 It works! Let’s go show Todd and Gina...;
2.20 Reviewing the alternate path;
2.21 Test drive, version 2.1;
2.22 Delivering the new dog door;
2.23 Working app, happy customers;
Chapter 3: Requirements Change: I Love You, You’re Perfect... Now Change;
3.1 You’re a hero!;
3.2 But then came a phone call...;
3.3 Back to the drawing board;
3.4 The one constant in software analysis and designIf you’ve read Head First Design Patterns, this page might look a bit familiar. They did such a good job describing change that we decided to just rip off their ideas, and just CHANGE a few things here and there. Thanks, Beth and Eric!;
3.5 Optional Path? Alternate Path? Who can tell?;
3.6 Use cases have to make sense to you;
3.7 Start to finish: a single scenario;
3.8 Let’s get ready to code...;
3.9 Finishing up the requirements list;
3.10 Now we can start coding the dog door again;
3.11 Was that a “woof” I heard?;
3.12 Power up the new dog door;
3.13 Updating the dog door;
3.14 Simplifying the remote control;
3.15 A final test drive;
3.16 More Tools for your OOA&D Toolbox;
Chapter 4: Analysis: Taking Your Software into the Real World;
4.1 One dog, two dog, three dog, four...;
4.2 Your software has a context;
4.3 Identify the problem;
4.4 Plan a solution;
4.5 Update your use case;
4.6 A tale of two coders;
4.7 Comparing barks;
4.8 Delegation in Sam’s dog door: an in-depth look;
4.9 The power of loosely coupled applications;
4.10 Back to Sam, Randy, and the contest...;
4.11 Maria won the MacBook Pro!;
4.12 So what did Maria do differently?;
4.13 Pay attention to the nouns in your use case;
4.14 It’s all about the use case;
4.15 There is no Bark class here!;
4.16 One of these things is not like the other...;
4.17 Remember: pay attention to those nouns!;
4.18 From good analysis to good classes...;
4.19 Class diagrams dissected;
4.20 Class diagrams aren’t everything;
4.21 So how does recognize() work now?;
Chapter 5: (Part 1) Good Design = Flexible Software: Nothing Ever Stays the Same;
5.1 Rick’s Guitars Stringed Instruments is expanding;
5.2 Let’s put our design to the test;
5.3 Did you notice that abstract base class?;
5.4 We’ll need a MandolinSpec class, too;
5.5 Behold: Rick’s new application;
5.6 Class diagrams dissected (again);
5.7 Let’s code Rick’s new search tool;
5.8 Create an abstract class for instrument specifications;
5.9 Let’s code GuitarSpec...;
5.10 ... and MandolinSpec, too;
5.11 Finishing up Rick’s search tool;
5.12 Uh oh... adding new instruments is not easy!;
5.13 So what are we supposed to do now?;
5.14 OO CATASTROPHE: Objectville’s Favorite Quiz Show;
5.15 “What is an INTERFACE?”;
5.16 “What is ENCAPSULATION?”;
5.17 “What is CHANGE?”;
5.18 (part 2) good design = flexible software: Give Your Software a 30-minute Workout;
5.19 Back to Rick’s search tool;
5.20 A closer look at the search() method;
5.21 The benefits of our analysis;
5.22 A closer look at the instrument classes;
5.23 But classes are really about behavior!;
5.24 Death of a design (decision);
5.25 Let’s turn some bad design decisions into good ones;
5.26 One more cubicle conversation (and some help from Jill);
5.27 “Double encapsulation” in Rick’s software;
5.28 Getting dynamic with instrument properties;
5.29 What we did: a closer look;
5.30 Using the new Instrument and InstrumentSpec classes;
5.31 Finishing up Rick’s app: the InstrumentType enum;
5.32 Let’s update Inventory, too;
5.33 Behold: Rick’s flexible application;
5.34 But does the application actually work?;
5.35 Test driving Rick’s well-designed software;
5.36 Rick’s got working software, his client has three choices;
5.37 Sweet! Our software is easy to change... but what about that “cohesive” thing?;
5.38 Cohesion, and one reason for a class to change;
5.39 Rick’s software, in review;
5.40 Knowing when to say “It’s good enough!”;
Chapter 6: Solving Really Big Problems: “My Name is Art Vandelay... I am an Architect”;
6.1 It’s all in how you look at the big problem;
6.2 The things you already know...;
6.3 So let’s solve a BIG problem!;
6.4 We need a lot more information;
6.5 What is the system like?;
6.6 What is the system not like?;
6.7 Customer Conversation;
6.8 Figure out the features;
6.9 But what is a feature, anyway?;
6.10 Use case diagrams;
6.11 The Little Actor;
6.12 Actors are people, too (well, not always);
6.13 Use case diagram... check! Features covered... check!;
6.14 So what exactly have we done?;
6.15 Cubicle Conversation;
6.16 Let’s do a little domain analysis!;
6.17 What most people give the customer...;
6.18 What we’re giving the customer...;
6.19 Now divide and conquer;
6.20 Don’t forget who your customer really is;
6.21 What’s a design pattern? And how do I use one?;
6.22 Feeling a little bit lost?;
6.23 The power of OOA&D (and a little common sense);
Chapter 7: Architecture: Bringing Order to Chaos;
7.1 Feeling a little overwhelmed?;
7.2 We need an architecture;
7.3 Architecture takes a big chaotic mess...;
7.4 ... and helps us turn it into a well-ordered application;
7.5 Let’s start with functionality;
7.6 But which of these are the most important?;
7.7 The three Qs of architecture;
7.8 1. Is it part of the essence of the system?;
7.9 2. What the fuck does it mean?;
7.10 3. How the “heck” do I do it?;
7.11 We’ve got a lot less chaos now...;
7.12 ... but there’s still plenty left to do;
7.13 Cubicle Argument Conversation;
7.14 The Tile and Unit classes;
7.15 More order, less chaos;
7.16 Which feature should we work on next?;
7.17 Game-specific units... what does that mean?;
7.18 Commonality revisited;
7.19 Solution #1: It’s all different!;
7.20 Solution #2: It’s all the same!;
7.21 Commonality analysis: the path to flexible software;
7.22 And still more order...;
7.23 What does it mean? Ask the customer;
7.24 Do you know what “coordinating movement” means?;
7.25 Now do some commonality analysis;
7.26 So now what would you do?;
7.27 Is there anything common here?;
7.28 It’s “different for every game”;
7.29 Reducing risk helps you write great software;
Chapter 8: Design Principles: Originality is Overrated;
8.1 Design principle roundup;
8.2 Principle #1: The Open-Closed Principle (OCP);
8.3 Remember working on Rick’s Stringed Instruments?;
8.4 The OCP, step-by-step;
8.5 Principle #2: The Don’t Repeat Yourself Principle (DRY);
8.6 DRY is really about ONE requirement in ONE place;
8.7 Principle #3: The Single Responsibility Principle (SRP);
8.8 Spotting multiple responsibilities;
8.9 Going from multiple responsibilities to a single responsibility;
8.10 Contestant #4: The Liskov Substitution Principle (LSP);
8.11 Misusing subclassing: a case study in misusing inheritance;
8.12 LSP reveals hidden problems with your inheritance structure;
8.13 “Subtypes must be substitutable for their base types”;
8.14 Violating the LSP makes for confusing code;
8.15 Solving the 3DBoard problem without using inheritance;
8.16 Delegate functionality to another class;
8.17 When to use delegation;
8.18 Use composition to assemble behaviors from other classes;
8.19 When to use composition;
8.20 When the pizza is gone, so are the ingredients...;
8.21 Aggregation: composition, without the abrupt ending;
8.22 Aggregation versus composition;
8.23 Inheritance is just one option;
Chapter 9: Iterating and Testing: The Software is Still for the Customer;
9.1 Your toolbox is filling up;
9.2 But you’re still writing your software for the CUSTOMER!;
9.3 Iterating deeper: two basic choices;
9.4 Feature driven development;
9.5 Use case driven development;
9.6 Two approaches to development;
9.7 Let’s use feature driven development;
9.8 Analysis of a feature;
9.9 Fleshing out the Unit class;
9.10 Showing off the Unit class;
9.11 Writing test scenarios;
9.12 Solution #1: Emphasizing Commonality;
9.13 Solution #2: Emphasizing Encapsulation;
9.14 Let’s go with the commonality-focused solution;
9.15 Match your tests to your design;
9.16 Let’s write the Unit class;
9.17 Test cases dissected...;
9.18 Prove yourself to the customer;
9.19 We’ve been programming by contract so far;
9.20 Programming by contract is really all about trust;
9.21 And we can always change the contract if we need to...;
9.22 But if you don’t trust your users...;
9.23 -or if they don’t trust you...;
9.24 Moving units;
9.25 Break your apps up into smaller chunks of functionality;
Chapter 10: The OOA&D Lifecycle: Putting It All Together;
10.1 Developing software, OOA&D style;
10.2 The problem;
10.3 Now you should really know what you’re supposed to do;
10.4 Use cases reflect usage, features reflect functionality;
10.5 Now start to iterate;
10.6 A closer look at representing a subway;
10.7 Let’s take a look at that subway file;
10.8 Let’s see if our use case works;
10.9 To use a Line class or not to use a Line class... that is the question;
10.10 Code the Station class;
10.11 Code the Subway class;
10.12 Points of interest on the Objectville Subway (class);
10.13 Protecting your classes (and your client’s classes, too);
10.14 The SubwayLoader class;
10.15 It’s time to iterate again;
10.16 But before we start Iteration 2...;
10.17 What’s left to do?;
10.18 Back to the requirements phase...;
10.19 Focus on code, then focus on customers. Then focus on code, then focus on customers...;
10.20 Iteration makes problems easier;
10.21 Implementation: Subway.java;
10.22 What does a route look like?;
10.23 One last test class...;
10.24 Check out Objectville for yourself!;
10.25 Iteration #3, anyone?;
10.26 The journey’s not over...;
10.27 Now take OOA&D for a spin on your own projects!;
Leftovers: The Top Ten Topics (we didn’t cover);
#1. IS-A and HAS-A;
The problem with IS-A and HAS-A;
#2. Use case formats;
Focusing on interaction;
A more formal use case;
#3. Anti patterns;
#4. CRC cards;
CRC cards help implement the SRP;
#5. Metrics;
#6. Sequence diagrams;
#7. State diagrams;
#8. Unit testing;
What a test case looks like;
#9. Coding standards and readable code;
Great software is more than just working code;
#10. Refactoring;
Welcome to Objectville: Speaking the Language of OO;
Welcome to Objectville;
UML and class diagrams;
Next up: inheritance;
And polymorphism, too...;
Last but not least: encapsulation;
Now anyone can set the speed directly;
So what’s the big deal?;

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing 1 Customer Reviews
  • Anonymous

    Posted January 17, 2008

    A reviewer

    This book is a terrific introduction to object-oriented programming. I have seen many developers thumb their noses at it because it is not high-level enough for their liking, but they need to get over themselves. This book is not intended to be picked up by someone that just graduated from Berkeley with a masters in computer science. It is intended for anyone that wants to understand the principles behind OOP and pick up the rhyme and reason to design patterns. If want to make the transition to OOP but don¿t really understand the basics, this book is perfect for you. So many languages support OOP and now with AS3 joining the group, both Flash and Flex projects can be built using reusible classes saving you hours of rewriting code.

    Was this review helpful? Yes  No   Report this review
Sort by: Showing 1 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)