Book Review: Head First Object-Oriented Analysis and Design

   

Books Index

by Brett McLaughlin, Gary Pollice, and David West
Publisher: O'Reilly Media, Inc.
ISBN: 0-596-00867-8
Publication Date: December 2006

Reviewed by Robert Eckstein
February 2007

If you haven't seen a "Head First" book before, you're in for a treat: The series tosses out the concept of the dry, technical educational book that we all suffered through in programming class -- and occasionally still suffer through -- and replaces it with something that's a lot of fun. For example, nearly every programmer I know has a copy of the Gang of Four Design Patterns book. And although there was a concerted effort in the late 1990s to embrace and extend the original Gang of Four book with a library of new titles, the resulting books often felt like photocopies whose extensions were highly debatable. (I remember one in particular in which the author simply borrowed common graphical user interface [GUI] designs, graphed out the appropriate diagrams, and credited himself for the pattern by using a name and year syntax such as [ECKSTEIN99].) In short, it takes a unique kind of book to truly build off a classic, and so far, Head First Design Patterns is the best approach I've seen.

Learning Object-Oriented Analysis and Design

And now, the Head First series attacks the arcane and often intimidating world of object-oriented analysis and design (OOA&D). If you're like me and have simply dismissed many of the OOA&D concepts for a good set of reusable design patterns over the years, you'll be glad to know that you can learn -- or relearn -- some of those hard-core principles that you gleaned from texts such as Booch ( Object-Oriented Analysis and Design With Applications) and Rumbaugh ( Object-Oriented Modeling and Design With UML) many years ago.

Whenever I get a new OOA&D book, one of the first topics that I look up is the old inheritance-versus-delegation debate. The crux of the argument is simple: Should I extend an object whose functionality I wish to use or simply include a reference to a class of that type inside my object and delegate calls to it?

In other words, when do I use this construct?

public class A extends B {}

And when do I use this?

public class A {

    public B myBObject;

}

Most OOA&D texts will tell you to favor delegation instead of inheritance by paraphrasing the Liskov Substitution Principle (LSP) -- a subclass must always be able to function as its superclass without screwing things up -- and Head First Object-Oriented Analysis and Design passes the test, with large bold letters at the bottom of pages 400 and 407. One nice side effect of doing so that I've often encountered is that delegation helps to support loose coupling. This gives you the freedom to swap out different types of delegates at runtime by programming toward an interface or abstract base class to represent the delegate instead of the class type itself. After all, it's impossible to dynamically swap an object's superclass at runtime. Head First Object-Oriented Analysis and Design satisfies this test as well by jumping into discussions on composition and aggregation starting on page 408.

Chapter Contents

But I'm getting ahead of myself. Let's start off with Chapter 1, which introduces the reader to a simple guitar-store inventory application that is, put simply, a mess. The book introduces three succinct steps in writing effective software, then uses those steps to illustrate some basic problems with the application. First, the authors use enums instead of Strings for guitar classifications. This is good, but remember that enums exist only in JDK 5.0 and later. You can use String constants instead if you're using JDK 1.4 or earlier versions. Second, they encapsulate behavior back to its primary class to make the software easier to maintain, which is always a good idea. My sole criticism of this chapter comes on page 45, and you'll likely catch it right off the bat: The writers should have used the Java technology-standard equals() for the name of their GuitarSpec method that tests for object equality -- instead of matches() -- or at least discussed why they decided against it. (Note to authors: If I'm missing something here, feel free to send me an email and I'll post your response.) After all, the book introduces the equals() method as a potential delegate only two pages earlier.

Chapters 2, 3, and 4 introduce use cases through the context of gathering requirements for the desired system. In this case, you're looking at the ins and outs of designing a theoretical doggy door that works in the real world. It's a little harder than you might imagine, especially because the book keeps dumping more and more requirements on its poor brunette-in-a-denim-jacket software engineer. First, the door has to close automatically after a specified amount of time -- this keeps other critters out. Then, the door has to open automatically to the sound of the dog's bark. But that introduces more problems, because you don't want the neighbor's constantly barking dog to be able to activate it. At the same time, you must realize that your dog can have multiple types of barks. Ultimately, the chapters force you to write out your use cases and focus on the nouns, which typically represent individual classes in your software.

It's a fun read, although at times you may feel that you could punch some easy holes in the authors' use cases. For example, at one point, the use case contains two routes: The dog goes out the door, does its business, and gets back in before the door closes; or the dog goes out the door and remains there after the door closes, waiting until the door is opened again. However, on page 82, you learn that the timer on the door is set to only five seconds. For the life of me, I can't think of any dog that can go out, do its business, and get back in within five seconds! It might have been more realistic to say that the dog rushed back inside for some reason -- weather, an army of maniacal fire hydrants in the back yard thirsting for revenge, and so on. This a bit of a nitpick, but I had to flag it because the chapters tell us in more than one location to consider "real-world contexts."

Chapter 5 -- all three parts of it -- hammer in the idea that change is inevitable in your systems, so you'd better get used to it and write your code with that fact in mind. The authors revisit the guitar-store inventory system from Chapter 1 and redesign it using abstract classes and interfaces, with a small break in the middle to play a Jeopardy! knockoff called OO Catastrophe! This section had me cracking up, and when I got to Final Catastrophe!, I found myself ignoring my email for a good 45 minutes. If you're not familiar with Unified Modeling Language (UML), this chapter also has some good information on the notations.

Chapters 6 and 7 apply the principles that the reader has learned so far in the analysis and design of a strategy game. These chapters are also very useful, but most readers will actively bookmark Chapter 8, which talks about design principles. The Open-Closed Principle (once a class works, don't change it, just extend it), the Don't Repeat Yourself Principle, the Single Responsibility Principle, and the aforementioned Liskov Substitution Principle are all concepts that all application designers should tuck into their utility belts. Having a firm grasp on these concepts is what separates the senior programmers from the junior programmers. The best part about this chapter is that it not only explains the principles but also discusses them in the context of real-world scenarios.

Chapter 9 drives home the idea that writing great software is an iterative, cyclical process. I learned this concept early on in my programming career, back when my superiors were fascinated with the waterfall model of software development. It didn't take many supposedly really, really simple maintenance requests before I realized that my colleagues and I were actually implementing a spiral model. However, this chapter goes a bit further and pairs this iterative process with its natural counterpart: testing. Each time you make a change, you need to run those tests. Each time you extend your classes, you need to create those tests. Testing is a major part of software development, folks. Don't let anyone tell you otherwise.

Finally, Chapter 10 puts everything together, reiterating all the concepts that the reader has learned throughout the book. One of the fun things to look at in this chapter is on pages 490 and 491: The Objectville subway map pairs together a number of OOA&D concepts and influential designers into a road map that the authors use for the remainder of the chapter examples. It's definitely inventive.

Conclusion

Peppered throughout the book are many common-sense principles that you're probably already familiar with, even if you've never laid hands on an OOA&D text. This book casually initiates free-form discussions as to why these principles are such a good idea. That's good news if you ever find yourself in a code review where that annoying intern who favors simplicity keeps asking why you introduced a more complex design pattern or principle in your code. And at around 600 pages, the book provides plenty of material to beat the intern over the head with if he doesn't buy your argument.

So all in all, this is a solid book to start exploring the world of OOA&D. It's not the be-all and end-all that you might be expecting -- and a useful appendix in the back discusses several concepts that the authors purposely avoided -- but it's a great title not only to learn the basics but to learn them well. That being said, I did catch a few misspellings and subject-verb disagreements, and I disagreed with the occasional “code magnet” examples which made me feel like I was just learning the Java language, but the strength of the book's material strongly eclipses such distractions.

One final word: I need to disclose that I used to work for O'Reilly Media, Inc. as an editor, back when it was called O'Reilly and Associates, Inc., and I know the primary author personally. That being said, I don't get any royalties from this book, nor does O'Reilly or any of the authors reward me in any way for reviewing it, other than providing me with a free copy of the book.

Catalog Page

Curious about this book? Take a look at its catalog page at the publisher's web site.

Ordering Information

O'Reilly
Amazon.com
Bookpool.com

By the Way

If you are a Java technology publisher and would like me to review your Java SE, Java ME, or Java EE book, don't hesitate: Send me an email right now. No, I mean it. Stop what you're doing and write me. Have you contacted me yet? OK, good. And now for my standard disclaimer: I won't review every book I receive, but we all know that there are some gems out there that really deserve the limelight. So let me know what they are.

Rate and Review
Tell us what you think of the content of this page.
Excellent   Good   Fair   Poor  
Comments:
Your email address (no reply is possible without an address):
Sun Privacy Policy

Note: We are not able to respond to all submitted comments.
Left Curve
Java SDKs and Tools
Right Curve
Left Curve
Java Resources
Right Curve
JavaOne Banner Java 8 banner (182)