Other Sellers on Amazon
Head First Object-Oriented Analysis and Design 1st Edition
Enhance your purchase
--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
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 are communicating 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!
From the brand
From the Publisher
About 'Head First' Books
We think of a Head First Reader as a Learner
Learning isn't something that just happens to you. It's something you do. You can't learn without pumping some neurons. Learning means building more mental pathways, bridging connections between new and pre-existing knowledge, recognizing patterns, and turning facts and information into knowledge (and ultimately, wisdom). Based on the latest research in cognitive science, neurobiology, and educational psychology, Head First books get your brain into learning mode.
Here's how we help you do that:
We tell stories using casual language, instead of lecturing. We don't take ourselves too seriously. Which would you pay more attention to: a stimulating dinner party companion, or a lecture?
We make it visual. Images are far more memorable than words alone, and make learning much more effective. They also make things more fun.
We use attention-grabbing tactics. Learning a new, tough, technical topic doesn't have to be boring. The graphics are often surprising, oversized, humorous, sarcastic, or edgy. The page layout is dynamic: no two pages are the same, and each one has a mix of text and images.
Metacognition: thinking about thinking
If you really want to learn, and you want to learn more quickly and more deeply, pay attention to how you pay attention. Think about how you think. The trick is to get your brain to see the new material you're learning as Really Important. Crucial to your well-being. Otherwise, you're in for a constant battle, with your brain doing its best to keep the new content from sticking.
Here's what we do:
We use pictures, because your brain is tuned for visuals, not text. As far as your brain's concerned, a picture really is worth a thousand words. And when text and pictures work together, we embedded the text in the pictures because your brain works more effectively when the text is within the thing the text refers to, as opposed to in a caption or buried in the text somewhere.
We use redundancy, saying the same thing in different ways and with different media types, and multiple senses, to increase the chance that the content gets coded into more than one area of your brain.
We use concepts and pictures in unexpected ways because your brain is tuned for novelty, and we use pictures and ideas with at least some emotional content, because your brain is more likely to remember when you feel something.
We use a personalized, conversational style, because your brain is tuned to pay more attention when it believes you're in a conversation than if it thinks you're passively listening to a presentation.
We include many activities, because your brain is tuned to learn and remember more when you do things than when you read about things. And we make the exercises challenging-yet-do-able, because that's what most people prefer.
We use multiple learning styles, because you might prefer step-by-step procedures, while someone else wants to understand the big picture first, and someone else just wants to see an example. But regardless of your own learning preference, everyone benefits from seeing the same content represented in multiple ways.
We include content for both sides of your brain, because the more of your brain you engage, the more likely you are to learn and remember, and the longer you can stay focused. Since working one side of the brain often means giving the other side a chance to rest, you can be more productive at learning for a longer period of time.
We include challenges by asking questions that don't always have a straight answer, because your brain is tuned to learn and remember when it has to work at something.
Finally, we use people in our stories, examples, and pictures, because, well, you're a person. Your brain pays more attention to people than to things.
About 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 firstname.lastname@example.org, and if he is not with customers or drinking warm beer with his friends in Boston, he will email you back.
- Publisher : O'Reilly Media; 1st edition (December 19, 2006)
- Language : English
- Paperback : 636 pages
- ISBN-10 : 0596008678
- ISBN-13 : 978-0596008673
- Item Weight : 2.65 pounds
- Dimensions : 8 x 1.38 x 9.25 inches
- Best Sellers Rank: #88,642 in Books (See Top 100 in Books)
- Customer Reviews:
About the authors
Reviews with images
Top reviews from the United States
There was a problem filtering reviews right now. Please try again later.
Head First OOA&D is a good first step for those of us that have OOP knowledge but are just beginning to learn how to architect OO software correctly. The book does sort of sit in an akward position for the target audience. On one hand this book assumes that you have OOP knowledge so it's not really for the OO beginner (the appendix covering OOP is quite shallow). On the other hand the examples in the book are extremely simplistic so those of us that do have OOP knowledge may desire a bit more out of the book. Don't let this shy you away though because like most Head First books - you will learn a good deal if your experience in OOA&D is very minimal.
I understand where this book is trying to aim. People looking into OOA&D should already have basic OOP concepts mastered. Some people tend to blur the line between OOA&D and OOP. OOA&D is Object Oriented Analysis and Design. This means you take the concepts you know from OOP and learn how to architect software by using certain techniques such as UML modeling, patterns, requirements gathering and what-not. OOP should already be understood if you are trying to create an OO architecture. In other words - You have to learn how buildings work before you learn how to draw the blue-prints and design your own building.
For what it is this is a very good book. If you are brand new to OOP then I would hold off on this one for a bit until OOP is understood. If you understand how OOP works but you don't feel confident architecting software then this is a great start even though the book may seem a bit overly simplistic at times.
The short conclusion is that I think this book, though a bit outdated with java 1.5 or whatever, does get a lot of good points across as far as how to consider design of classes, program layout, and whatever. At the same time, I didn't find it particularly enlightening, like a lot of it just seemed like common sense when it asked me to solve some things, and some things I don't even completely agree with but arguably that's part of the book's ideas it is trying to get across to the reader. It may be too simple for anybody who's done a bit of professional software work (like maybe they'd pick it up on the job or something), but I think it's a constructive book for anybody who maybe can't quite wrap their head around why their code is so spaghetti like or why their objects have serious copy/paste issues or poor reusability/encapsulation or something.
I think i'd recommend it to anybody taking computer science in high school level? but then again i didn't take any CS classes in high school so that may be a reach also.
You can tell that the first chapter was rushed. There are several spelling and programming mistakes. The most egregious is where they ask you to look through some code to find what "FIRST" you change and then they answer that question with a much smaller problem (the main problem was they forgot to add a return statement (pg.5) and they write about the inconsistency of using String based searching). It has also been mentioned by several reviewers of the use of the method name "matches" which only makes sense for regex not for an equals operation. I also did not like the search example (how can you not think of price in a search?). The best part of this chapter is the mantra that should be practiced by many engineers: "Make sure your software does what the customer wants it to do."
The next few chapters are definitely better (though still some spelling mistakes). They are a good read for beginners and intermediate programmers on gathering requirements, change of these requirements and analysis. The ideas are a bit simplistic though it is good to get many programmers used to the idea of UML and use cases and using them to drive requirement gathering and textual analysis. Intermediate and advanced readers familiar with use cases will gain more from reading Alistair Cockburn's "Writing Effective Use Cases" (or will already have read it) and for further UML reading should go with "UML Distilled" by Martin Fowler.
When the book gets back to design I see some problems with the coding. The designer has this bizarre idea of abstracting all properties (under the guise of "encapsulate what varies") into a Map attribute to lessen the amount of subclasses for instruments. While initially this may seem a good idea it gets rid of all type-safe coding (you can now safely assign an instrument type to a backwood for the instrument), you cannot have behavior from the instruments (this is mentioned in the book) and if you put a property with one letter misspelled or capitalized out-of-place you now have a bug, one that you might have trouble finding thereby increasing maintenance costs. Too much flexibility makes the code ambiguous.
After design, the studies get to solving really big problems, architecture, design principles, and iterating and testing. These chapters I enjoyed much more especially the chapter on design principles with the beginning mantra that "Originality is Overrated." This chapter goes over basic principles such as OCP (open-closed principle), DRY (don't repeat yourself), SRP (single responsibility principle) and LSP (Liskov Substitution Principle).
Then the book last chapter (the ooa&d lifecycle) sums the lessons in the book in one large (somewhat contrived but these type of examples always are) program for the Objectville Subway. Then two terse appendixes dealing with ten additional OOA&D topics and OO concepts should make the reader realize that this book is just an introductory sliver of what needs to be learned for a sagacious software acumen.
This book is useful for programmers with a bit of Java (or C#) knowledge who want to get a good overview of OOA&D. This book is useful because it teaches important OO vernacular and a simple holistic approach to iterative development. If the book did not have a "quickly done" feeling, better design and fewer mistakes I would have liked this book more. This book is a good candidate for a second edition. If you want a more thorough explanation of these topics I recommend "The Object Primer" by Scott Ambler as one of my favorite books for a good introduction to OOA&D.
Top reviews from other countries
My first impression was that it was fairly dull, and I actually put it aside about halfway through to read something else. I came back to it last week and finished it off, and ended up very pleased with it.
If you're a programmer (like me), you'll probably be frustrated by the lack of code in the first half of the book. In fairness, this is more a factor of the design process. Much as we love to jump in and start coding, this isn't the best way to do it. This book teaches the way it should be done, so you don't get to write code until some time later.
Once you've got to the end, the whole process seems much clearer and easier to follow than it looked earlier. The book ends with a decent case study of analysis of an application to work out routes on a subway, and working through this clarified what the rest of the book had been explaining.
So, if you're prepared for the fact that "doing it the right way" means not writing code straight away, then this book is excellent.
HOWEVER, there is a big negative against this book, and this is something the Head First people need to think about as it affected the otherwise excellent Head First Design Patterns in the same way...
Amazing as it may seem, there are some people who write applications in languages other than Java. I know the Head First team won't believe this, but Java isn't the only OO language out there. In fact, I'll let you into a secret, design patterns and OO analysis are actually language agnostic. You don't need to tie yourself to ANY language. You can teach all this stuff without tying yourself down to any specific language.
Sure, when you supply code, you have to use a language, and I don't think anyone would have any strong objections to that language being Java. It's a common, fully OO language, whose syntax is so close to C# and C++ that programmers in those languages shouldn't have any problem reading the Java.
The problem is when the text and explanation keep droning on about Java when it's irrelevant, and (worse) when they use Java-specific things in the code. There is no necessity for this, and it makes the book less accessible for non-Java developers. It would be really easy to have written this book in a language-agnostic way, even with code samples in Java. This is something that really needs to be done for both of these books, and would have made both of them five star books.