Head First Object-Oriented Analysis and Design. A Brain Friendly Guide to OOA&D

Kup polskie wydanie:

Spis treści książki

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

pokaż cały spis treści

ukryj recenzje