Head First Object-Oriented Analysis & Design

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 Commonality; 9.13 Solution #2: Emphasizing Encapsulation; 9.14 Let's go with the commonality-focused solution; 9.15 Match your tests to your design; 9.16 Let's write the Unit class; 9.17 Test cases dissected...; 9.18 Prove yourself to the customer; 9.19 We've been programming by contract so far; 9.20 Programming by contract is really all about trust; 9.21 And we can always change the contract if we need to...; 9.22 But if you don't trust your users...; 9.23 -or if they don't trust you...; 9.24 Moving units; 9.25 Break your apps up into smaller chunks of functionality;Chapter 10: The OOA&D Lifecycle: Putting It All Together; 10.1 Developing software, OOA&D style; 10.2 The problem; 10.3 Now you should really know what you're supposed to do; 10.4 Use cases reflect usage, features reflect functionality; 10.5 Now start to iterate; 10.6 A closer look at representing a subway; 10.7 Let's take a look at that subway file; 10.8 Let's see if our use case works; 10.9 To use a Line class or not to use a Line class... that is the question; 10.10 Code the Station class; 10.11 Code the Subway class; 10.12 Points of interest on the Objectville Subway (class); 10.13 Protecting your classes (and your client's classes, too); 10.14 The SubwayLoader class; 10.15 It's time to iterate again; 10.16 But before we start Iteration 2...; 10.17 What's left to do?; 10.18 Back to the requirements phase...; 10.19 Focus on code, then focus on customers. Then focus on code, then focus on customers...; 10.20 Iteration makes problems easier; 10.21 Implementation: Subway.java; 10.22 What does a route look like?; 10.23 One last test class...; 10.24 Check out Objectville for yourself!; 10.25 Iteration #3, anyone?; 10.26 The journey's not over...; 10.27 Now take OOA&D for a spin on your own projects!;Leftovers: The Top Ten Topics (we didn't cover); #1. IS-A and HAS-A; The problem with IS-A and HAS-A; #2. Use case formats; Focusing on interaction; A more formal use case; #3. Anti patterns; #4. CRC cards; CRC cards help implement the SRP; #5. Metrics; #6. Sequence diagrams; #7. State diagrams; #8. Unit testing; What a test case looks like; #9. Coding standards and readable code; Great software is more than just working code; #10. Refactoring;Welcome to Objectville: Speaking the Language of OO; Welcome to Objectville; UML and class diagrams; Next up: inheritance; And polymorphism, too...; Last but not least: encapsulation; Now anyone can set the speed directly; So what's the big deal?;