O'Reilly logo

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Head First Object-Oriented Analysis and Design

Book Description

"Head First Object Oriented Analysis and Design is a refreshinglook at subject of OOAD. What sets this book apart is its focus onlearning. 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 thingI liked most about this book was its focus on why we doOOA&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 andDesign. As I read the book, I felt like I was looking over theshoulder of an expert designer who was explaining to me what issueswere important at each step, and why."Edward Sciore, Associate Professor, Computer Science Department,Boston College

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

But how?

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

  • Use OO principles like encapsulation and delegation to buildapplications that are flexible

  • Apply the Open-Closed Principle (OCP) and the SingleResponsibility Principle (SRP) to promote reuse of your code

  • Leverage the power of design patterns to solve your problemsmore efficiently

  • Use UML, use cases, and diagrams to ensure that allstakeholders are communicating clearly to help you deliver theright software that meets everyone's needs.

  • By exploiting how your brain works, Head FirstObject-Oriented Analysis & Design compresses the time ittakes to learn and retain complex information. Expect to have fun,expect to learn, expect to be writing great software consistentlyby the time you're finished reading this!

    Table of Contents

    1. Dedication
    2. Special Upgrade Offer
    3. A Note Regarding Supplemental Files
    4. Head First Object-Oriented Analysis & Design
    5. Praise for Head First OOA&D
    6. Praise for other Head First books by the authors
    7. Praise for other Head First Books
    8. How to use this Book: Intro
      1. Who is this book for?
      2. Who should probably back away from this book?
      3. We know what you’re thinking
      4. And we know what your brain is thinking
      5. Metacognition: thinking about thinking
      6. Here’s what WE did
      7. Here’s what YOU can do to bend your brain into submission
      8. Read Me
      9. The Technical Team
      10. Acknowledgements
      11. Special thanks
    9. 1. Well-Designed Apps Rock: Great Software Begins Here
      1. Rock and roll is forever!
      2. Rick’s shiny new application...
      3. Here what the code for Guitar.java looks like
      4. And Inventory.java...
      5. But then Rick started losing customers...
      6. What’s the FIRST thing you’d change?
      7. Great software is... more than just one thing
      8. Great software in 3 easy steps
      9. Remember Rick? Remember his lost customers?
      10. So let’s apply our 3 steps
      11. Ditching String comparisons
      12. Rick’s customers want choices!
      13. Test drive
      14. Back to our steps
      15. Looking for problems
      16. Analyze the search() method
      17. Now update your own code
      18. Update the Inventory class
      19. Getting ready for another test drive
      20. Getting back to Rick’s app...
      21. Design once, design twice
      22. Let’s make sure Inventory.java is (really) well-designed
      23. One last test drive (and an app ready for reuse)
      24. What we did
      25. Remember this poor guy?
      26. OOA&D is about writing great software, not doing a bunch of paperwork!
    10. 2. Gathering Requirements: Give Them What They Want
      1. You’ve got a new programming gig
      2. Todd and Gina: your first customer
      3. Let’s start with the dog door
      4. Test drive
      5. But when Gina tried it...
      6. Listen to the customer
      7. Creating a requirements list
      8. What does the dog door really need to do?
      9. Plan for things going wrong
      10. Alternate paths handle system problems
      11. (Re) introducing use cases
      12. One use case, three parts
      13. Checking your requirements against your use cases
      14. Is anything missing?
      15. So now can we write some code?
      16. Automatically closing the door
      17. We need a new simulator!
      18. Test drive, version 2.0
      19. It works! Let’s go show Todd and Gina...
      20. Reviewing the alternate path
      21. Test drive, version 2.1
      22. Delivering the new dog door
      23. Working app, happy customers
    11. 3. Requirements Change: I Love You, You’re Perfect... Now Change
      1. You’re a hero!
      2. But then came a phone call...
      3. Back to the drawing board
      4. The one constant in software analysis and design
      5. Optional Path? Alternate Path? Who can tell?
      6. Use cases have to make sense to you
      7. Start to finish: a single scenario
      8. Let’s get ready to code...
      9. Finishing up the requirements list
      10. Now we can start coding the dog door again
      11. Was that a “woof” I heard?
      12. Power up the new dog door
      13. Updating the dog door
      14. Simplifying the remote control
      15. A final test drive
      16. More Tools for your OOA&D Toolbox
    12. 4. Analysis: Taking Your Software into the Real World
      1. One dog, two dog, three dog, four...
      2. Your software has a context
      3. Identify the problem
      4. Plan a solution
      5. Update your use case
      6. A tale of two coders
        1. Randy: simple is best, right?
        2. Sam: object lover extraordinaire
        3. Sam: updating the DogDoor class
      7. Comparing barks
        1. Randy: I’ll just compare two strings
        2. Sam: I’ll delegate bark comparison
      8. Delegation in Sam’s dog door: an in-depth look
      9. The power of loosely coupled applications
      10. Back to Sam, Randy, and the contest...
        1. Randy AND Sam: It works!
      11. Maria won the MacBook Pro!
      12. So what did Maria do differently?
      13. Pay attention to the nouns in your use case
      14. It’s all about the use case
      15. There is no Bark class here!
      16. One of these things is not like the other...
        1. Focus: owner’s dog
        2. Focus: owner’s dog’s bark
      17. Remember: pay attention to those nouns!
      18. From good analysis to good classes...
      19. Class diagrams dissected
      20. Class diagrams aren’t everything
      21. So how does recognize() work now?
    13. 5. (Part 1) Good Design = Flexible Software: Nothing Ever Stays the Same
      1. Rick’s Guitars Stringed Instruments is expanding
      2. Let’s put our design to the test
      3. Did you notice that abstract base class?
      4. We’ll need a MandolinSpec class, too
      5. Behold: Rick’s new application
      6. Class diagrams dissected (again)
      7. Let’s code Rick’s new search tool
      8. Create an abstract class for instrument specifications
      9. Let’s code GuitarSpec...
      10. ... and MandolinSpec, too
      11. Finishing up Rick’s search tool
      12. Uh oh... adding new instruments is not easy!
      13. So what are we supposed to do now?
    14. 6.  
      1. “What is an INTERFACE?”?”
      2. “What is ENCAPSULATION?”?”
      3. “What is CHANGE?””
    15. 7. (part 2) good design = flexible software: Give Your Software a 30-minute Workout
      1. Back to Rick’s search tool
      2. A closer look at the search() method
      3. The benefits of our analysis
      4. A closer look at the instrument classes
      5. But classes are really about behavior!
      6. Death of a design (decision)
      7. Let’s turn some bad design decisions into good ones
      8. One more cubicle conversation (and some help from Jill)
      9. “Double encapsulation” in Rick’s software
      10. Getting dynamic with instrument properties
      11. What we did: a closer look
      12. Using the new Instrument and InstrumentSpec classes
      13. Finishing up Rick’s app: the InstrumentType enum
      14. Let’s update Inventory, too
      15. Behold: Rick’s flexible application
      16. But does the application actually work?
      17. Test driving Rick’s well-designed software
      18. Rick’s got working software, his client has three choices
      19. Sweet! Our software is easy to change... but what about that “cohesive” thing?
      20. Cohesion, and one reason for a class to change
      21. Rick’s software, in review
      22. Knowing when to say “It’s good enough!”
    16. 8. Solving Really Big Problems: “My Name is Art Vandelay... I am an Architect”
      1. It’s all in how you look at the big problem
      2. The things you already know...
      3. So let’s solve a BIG problem!
      4. We need a lot more information
      5. What is the system like?
      6. What is the system not like?
      7. Customer Conversation
      8. Figure out the features
      9. But what is a feature, anyway?
      10. Use case diagrams
        1. But there’s one feature still left... what up with that?
      11. The Little Actor
        1. A small Socratic exercise in the style of The Little Lisper
      12. Actors are people, too (well, not always)
      13. Use case diagram... check! Features covered... check!
      14. So what exactly have we done?
      15. Cubicle Conversation
      16. Let’s do a little domain analysis!
      17. What most people give the customer...
      18. What we’re giving the customer...
      19. Now divide and conquer
      20. Don’t forget who your customer really is
      21. What’s a design pattern? And how do I use one?
      22. Feeling a little bit lost?
      23. The power of OOA&D (and a little common sense)
    17. 9. Architecture: Bringing Order to Chaos
      1. Feeling a little overwhelmed?
      2. We need an architecture
      3. Architecture takes a big chaotic mess...
      4. ... and helps us turn it into a well-ordered application
      5. Let’s start with functionality
      6. But which of these are the most important?
      7. The three Qs of architecture
      8. 1. Is it part of the essence of the system?
      9. 2. What the fuck does it mean?
      10. 3. How the “heck” do I do it?
      11. We’ve got a lot less chaos now...
      12. ... but there’s still plenty left to do
      13. Cubicle Argument Conversation
      14. The Tile and Unit classes
        1. Keep the right focus
      15. More order, less chaos
        1. We’ve got structure now, too...
      16. Which feature should we work on next?
      17. Game-specific units... what does that mean?
      18. Commonality revisited
      19. Solution #1: It’s all different!
      20. Solution #2: It’s all the same!
      21. Commonality analysis: the path to flexible software
      22. And still more order...
      23. What does it mean? Ask the customer
      24. Do you know what “coordinating movement” means?
      25. Now do some commonality analysis
      26. So now what would you do?
      27. Is there anything common here?
      28. It’s “different for every game”
      29. Reducing risk helps you write great software
    18. 10. Design Principles: Originality is Overrated
      1. Design principle roundup
      2. Principle #1: The Open-Closed Principle (OCP)
        1. Closed for modication...
        2. ... but open for extension
      3. Remember working on Rick’s Stringed Instruments?
      4. The OCP, step-by-step
      5. Principle #2: The Don’t Repeat Yourself Principle (DRY)
        1. A prime place to apply DRY...
        2. 1. Let’s abstract out the common code
        3. 2. Now remove the code from other locations...
        4. 3. ...and reference the code from Step #1
      6. DRY is really about ONE requirement in ONE place
      7. Principle #3: The Single Responsibility Principle (SRP)
      8. Spotting multiple responsibilities
      9. Going from multiple responsibilities to a single responsibility
      10. Contestant #4: The Liskov Substitution Principle (LSP)
      11. Misusing subclassing: a case study in misusing inheritance
      12. LSP reveals hidden problems with your inheritance structure
      13. “Subtypes must be substitutable for their base types”
      14. Violating the LSP makes for confusing code
      15. Solving the 3DBoard problem without using inheritance
      16. Delegate functionality to another class
      17. When to use delegation
      18. Use composition to assemble behaviors from other classes
      19. When to use composition
      20. When the pizza is gone, so are the ingredients...
      21. Aggregation: composition, without the abrupt ending
        1. You’ve already used aggregation...
      22. Aggregation versus composition
      23. Inheritance is just one option
    19. 11. Iterating and Testing: The Software is Still for the Customer
      1. Your toolbox is filling up
      2. But you’re still writing your software for the CUSTOMER!
      3. Iterating deeper: two basic choices
      4. Feature driven development
      5. Use case driven development
      6. Two approaches to development
        1. What’s the difference between feature driven and use case driven development?
      7. Let’s use feature driven development
      8. Analysis of a feature
        1. 3. The framework supports multiple types of troops or units that are game-specific
      9. Fleshing out the Unit class
      10. Showing off the Unit class
      11. Writing test scenarios
        1. Scenario #2: Changing property values
        2. Scenario #3: Getting non-existent property values
      12. Solution #1: Emphasizing Commonality
        1. Design decisions are always a tradeoff
      13. Solution #2: Emphasizing Encapsulation
        1. Tradeoffs with this decision, too...
      14. Let’s go with the commonality-focused solution
      15. Match your tests to your design
      16. Let’s write the Unit class
      17. Test cases dissected...
      18. Prove yourself to the customer
      19. We’ve been programming by contract so far
        1. This is the contract for Unit
      20. Programming by contract is really all about trust
      21. And we can always change the contract if we need to...
      22. But if you don’t trust your users...
      23. -or if they don’t trust you...
      24. Moving units
        1. Haven’t we been here before?
      25. Break your apps up into smaller chunks of functionality
        1. But you can still break things up further...
        2. Your decisions can iterate down, too
    20. 12. The OOA&D Lifecycle: Putting It All Together
      1. Developing software, OOA&D style
      2. The problem
      3. Now you should really know what you’re supposed to do
      4. Use cases reflect usage, features reflect functionality
      5. Now start to iterate
      6. A closer look at representing a subway
        1. What is a station?
        2. And a connection between two stations?
        3. Then a line is just a series of connections...
      7. Let’s take a look at that subway file
      8. Let’s see if our use case works
      9. To use a Line class or not to use a Line class... that is the question
      10. Code the Station class
      11. Code the Subway class
      12. Points of interest on the Objectville Subway (class)
        1. What Java’s default equals() implementation does...
        2. What our equals() implementation does...
      13. Protecting your classes (and your client’s classes, too)
      14. The SubwayLoader class
      15. It’s time to iterate again
      16. But before we start Iteration 2...
      17. What’s left to do?
      18. Back to the requirements phase...
      19. Focus on code, then focus on customers. Then focus on code, then focus on customers...
      20. Iteration makes problems easier
      21. Implementation: Subway.java
      22. What does a route look like?
      23. One last test class...
      24. Check out Objectville for yourself!
      25. Iteration #3, anyone?
        1. Make loading more extensible
        2. Allow different output sources (and formats!)
      26. The journey’s not over...
      27. Now take OOA&D for a spin on your own projects!
    21. A. Leftovers: The Top Ten Topics (we didn’t cover)
      1. #1. IS-A and HAS-A
        1. IS-A refers to inheritance
        2. HAS-A refers to composition or aggregation
      2. The problem with IS-A and HAS-A
      3. #2. Use case formats
      4. Focusing on interaction
      5. A more formal use case
      6. #3. Anti patterns
      7. #4. CRC cards
      8. CRC cards help implement the SRP
      9. #5. Metrics
      10. #6. Sequence diagrams
      11. #7. State diagrams
      12. #8. Unit testing
      13. What a test case looks like
        1. Test your code in context
      14. #9. Coding standards and readable code
      15. Great software is more than just working code
      16. #10. Refactoring
    22. B. Welcome to Objectville: Speaking the Language of OO
      1. Welcome to Objectville
      2. UML and class diagrams
      3. Next up: inheritance
      4. And polymorphism, too...
      5. Last but not least: encapsulation
      6. Now anyone can set the speed directly
      7. So what’s the big deal?
    23. Index
    24. About the Authors
    25. Special Upgrade Offer
    26. Copyright