Books & Videos

Table of Contents

  1. Chapter 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!

  2. Chapter 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

  3. Chapter 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 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!

    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

  4. Chapter 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

    7. Comparing barks

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

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

    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?

  5. Chapter 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. OO CATASTROPHE: Objectville’s Favorite Quiz Show

    15. “What is an INTERFACE?”

    16. “What is ENCAPSULATION?”

    17. “What is CHANGE?”

    18. (part 2) good design = flexible software: Give Your Software a 30-minute Workout

    19. Back to Rick’s search tool

    20. A closer look at the search() method

    21. The benefits of our analysis

    22. A closer look at the instrument classes

    23. But classes are really about behavior!

    24. Death of a design (decision)

    25. Let’s turn some bad design decisions into good ones

    26. One more cubicle conversation (and some help from Jill)

    27. “Double encapsulation” in Rick’s software

    28. Getting dynamic with instrument properties

    29. What we did: a closer look

    30. Using the new Instrument and InstrumentSpec classes

    31. Finishing up Rick’s app: the InstrumentType enum

    32. Let’s update Inventory, too

    33. Behold: Rick’s flexible application

    34. But does the application actually work?

    35. Test driving Rick’s well-designed software

    36. Rick’s got working software, his client has three choices

    37. Sweet! Our software is easy to change... but what about that “cohesive” thing?

    38. Cohesion, and one reason for a class to change

    39. Rick’s software, in review

    40. Knowing when to say “It’s good enough!”

  6. Chapter 6 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

    11. The Little Actor

    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)

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

    15. More order, less chaos

    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

  8. Chapter 8 Design Principles: Originality is Overrated

    1. Design principle roundup

    2. Principle #1: The Open-Closed Principle (OCP)

    3. Remember working on Rick’s Stringed Instruments?

    4. The OCP, step-by-step

    5. Principle #2: The Don’t Repeat Yourself Principle (DRY)

    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

    22. Aggregation versus composition

    23. Inheritance is just one option

  9. Chapter 9 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

    7. Let’s use feature driven development

    8. Analysis of a feature

    9. Fleshing out the Unit class

    10. Showing off the Unit class

    11. Writing test scenarios

    12. Solution #1: Emphasizing Commonality

    13. Solution #2: Emphasizing Encapsulation

    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

    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

    25. Break your apps up into smaller chunks of functionality

  10. Chapter 10 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

    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)

    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?

    26. The journey’s not over...

    27. Now take OOA&D for a spin on your own projects!

  1. Appendix Leftovers: The Top Ten Topics (we didn’t cover)

    1. #1. IS-A and HAS-A

    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

    14. #9. Coding standards and readable code

    15. Great software is more than just working code

    16. #10. Refactoring

  2. Appendix 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?