;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; Acknowledgements; 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 Common.