book

Head First Object-Oriented Analysis and Design

by Brett McLaughlin, Gary Pollice, David West

November 2006

Beginner to intermediate

634 pages

13h 41m

English

O'Reilly Media, Inc.

Read now

Unlock full access

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 you’re thinkingAnd we know what your brain is thinkingMetacognition: thinking about thinkingHere’s what WE didHere’s what YOU can do to bend your brain into submissionRead MeThe Technical TeamAcknowledgementsSpecial thanks
1. Well-Designed Apps Rock: Great Software Begins Here
Rock and roll is forever!Rick’s shiny new application...Here what the code for Guitar.java looks likeAnd Inventory.java...But then Rick started losing customers...What’s the FIRST thing you’d change?Great software is... more than just one thingGreat software in 3 easy stepsRemember Rick? Remember his lost customers?So let’s apply our 3 stepsDitching String comparisonsRick’s customers want choices!Test driveBack to our stepsLooking for problemsAnalyze the search() methodNow update your own codeUpdate the Inventory classGetting ready for another test driveGetting back to Rick’s app...Design once, design twiceLet’s make sure Inventory.java is (really) well-designedOne last test drive (and an app ready for reuse)What we didRemember this poor guy?OOA&D is about writing great software, not doing a bunch of paperwork!
2. Gathering Requirements: Give Them What They Want
You’ve got a new programming gigTodd and Gina: your first customerLet’s start with the dog doorTest driveBut when Gina tried it...Listen to the customerCreating a requirements listWhat does the dog door really need to do?Plan for things going wrongAlternate paths handle system problems(Re) introducing use casesOne use case, three partsChecking your requirements against your use casesIs anything missing?So now can we write some code?Automatically closing the doorWe need a new simulator!Test drive, version 2.0It works! Let’s go show Todd and Gina...Reviewing the alternate pathTest drive, version 2.1Delivering the new dog doorWorking app, happy customers
3. Requirements Change: I Love You, You’re Perfect... Now Change
You’re a hero!But then came a phone call...Back to the drawing boardThe one constant in software analysis and designOptional Path? Alternate Path? Who can tell?Use cases have to make sense to youStart to finish: a single scenarioLet’s get ready to code...Finishing up the requirements listNow we can start coding the dog door againWas that a “woof” I heard?Power up the new dog doorUpdating the dog doorSimplifying the remote controlA final test driveMore 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 contextIdentify the problemPlan a solutionUpdate your use caseA tale of two codersRandy: simple is best, right?Sam: object lover extraordinaireSam: updating the DogDoor classComparing barksRandy: I’ll just compare two stringsSam: I’ll delegate bark comparisonDelegation in Sam’s dog door: an in-depth lookThe power of loosely coupled applicationsBack 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 caseIt’s all about the use caseThere is no Bark class here!One of these things is not like the other...Focus: owner’s dogFocus: owner’s dog’s barkRemember: pay attention to those nouns!From good analysis to good classes...Class diagrams dissectedClass diagrams aren’t everythingSo how does recognize() work now?

5. (Part 1) Good Design = Flexible Software: Nothing Ever Stays the Same
Rick’s Guitars Stringed Instruments is expandingLet’s put our design to the testDid you notice that abstract base class?We’ll need a MandolinSpec class, tooBehold: Rick’s new applicationClass diagrams dissected (again)Let’s code Rick’s new search toolCreate an abstract class for instrument specificationsLet’s code GuitarSpec...... and MandolinSpec, tooFinishing up Rick’s search toolUh oh... adding new instruments is not easy!So what are we supposed to do now?OO CATASTROPHE: Objectville’s 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 WorkoutBack to Rick’s search toolA closer look at the search() methodThe benefits of our analysisA closer look at the instrument classesBut classes are really about behavior!Death of a design (decision)Let’s turn some bad design decisions into good onesOne more cubicle conversation (and some help from Jill)“Double encapsulation” in Rick’s softwareGetting dynamic with instrument propertiesWhat we did: a closer lookUsing the new Instrument and InstrumentSpec classesFinishing up Rick’s app: the InstrumentType enumLet’s update Inventory, tooBehold: Rick’s flexible applicationBut does the application actually work?Test driving Rick’s well-designed softwareRick’s got working software, his client has three choicesSweet! Our software is easy to change... but what about that “cohesive” thing?Cohesion, and one reason for a class to changeRick’s software, in reviewKnowing when to say “It’s good enough!”
6. Solving Really Big Problems: “My Name is Art Vandelay... I am an Architect”
It’s all in how you look at the big problemThe things you already know...So let’s solve a BIG problem!We need a lot more informationWhat is the system like?What is the system not like?Customer ConversationFigure out the featuresBut what is a feature, anyway?Use case diagramsBut there’s one feature still left... what up with that?The Little ActorA small Socratic exercise in the style of The Little LisperActors are people, too (well, not always)Use case diagram... check! Features covered... check!So what exactly have we done?Cubicle ConversationLet’s do a little domain analysis!What most people give the customer...What we’re giving the customer...Now divide and conquerDon’t forget who your customer really isWhat’s 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 architectureArchitecture takes a big chaotic mess...... and helps us turn it into a well-ordered applicationLet’s start with functionalityBut which of these are the most important?The three Qs of architecture1. Is it part of the essence of the system?2. What the fuck does it mean?3. How the “heck” do I do it?We’ve got a lot less chaos now...... but there’s still plenty left to doCubicle Argument ConversationThe Tile and Unit classesKeep the right focusMore order, less chaosWe’ve got structure now, too...Which feature should we work on next?Game-specific units... what does that mean?Commonality revisitedSolution #1: It’s all different!Solution #2: It’s all the same!Commonality analysis: the path to flexible softwareAnd still more order...What does it mean? Ask the customerDo you know what “coordinating movement” means?Now do some commonality analysisSo now what would you do?Is there anything common here?It’s “different for every game”Reducing risk helps you write great software
8. Design Principles: Originality is Overrated
Design principle roundupPrinciple #1: The Open-Closed Principle (OCP)Closed for modication...... but open for extensionRemember working on Rick’s Stringed Instruments?The OCP, step-by-stepPrinciple #2: The Don’t Repeat Yourself Principle (DRY)A prime place to apply DRY...1. Let’s abstract out the common code2. Now remove the code from other locations...3. ...and reference the code from Step #1DRY is really about ONE requirement in ONE placePrinciple #3: The Single Responsibility Principle (SRP)Spotting multiple responsibilitiesGoing from multiple responsibilities to a single responsibilityContestant #4: The Liskov Substitution Principle (LSP)Misusing subclassing: a case study in misusing inheritanceLSP reveals hidden problems with your inheritance structure“Subtypes must be substitutable for their base types”Violating the LSP makes for confusing codeSolving the 3DBoard problem without using inheritanceDelegate functionality to another classWhen to use delegationUse composition to assemble behaviors from other classesWhen to use compositionWhen the pizza is gone, so are the ingredients...Aggregation: composition, without the abrupt endingYou’ve already used aggregation...Aggregation versus compositionInheritance is just one option
9. Iterating and Testing: The Software is Still for the Customer
Your toolbox is filling upBut you’re still writing your software for the CUSTOMER!Iterating deeper: two basic choicesFeature driven developmentUse case driven developmentTwo approaches to developmentWhat’s the difference between feature driven and use case driven development?Let’s use feature driven developmentAnalysis of a feature3. The framework supports multiple types of troops or units that are game-specificFleshing out the Unit classShowing off the Unit classWriting test scenariosScenario #2: Changing property valuesScenario #3: Getting non-existent property valuesSolution #1: Emphasizing CommonalityDesign decisions are always a tradeoffSolution #2: Emphasizing EncapsulationTradeoffs with this decision, too...Let’s go with the commonality-focused solutionMatch your tests to your designLet’s write the Unit classTest cases dissected...Prove yourself to the customerWe’ve been programming by contract so farThis is the contract for UnitProgramming by contract is really all about trustAnd we can always change the contract if we need to...But if you don’t trust your users...-or if they don’t trust you...Moving unitsHaven’t we been here before?Break your apps up into smaller chunks of functionalityBut 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 styleThe problemNow you should really know what you’re supposed to doUse cases reflect usage, features reflect functionalityNow start to iterateA closer look at representing a subwayWhat is a station?And a connection between two stations?Then a line is just a series of connections...Let’s take a look at that subway fileLet’s see if our use case worksTo use a Line class or not to use a Line class... that is the questionCode the Station classCode the Subway classPoints of interest on the Objectville Subway (class)What Java’s default equals() implementation does...What our equals() implementation does...Protecting your classes (and your client’s classes, too)The SubwayLoader classIt’s time to iterate againBut before we start Iteration 2...What’s 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 easierImplementation: Subway.javaWhat does a route look like?One last test class...Check out Objectville for yourself!Iteration #3, anyone?Make loading more extensibleAllow different output sources (and formats!)The journey’s not over...Now take OOA&D for a spin on your own projects!
A. Leftovers: The Top Ten Topics (we didn’t cover)
#1. IS-A and HAS-AIS-A refers to inheritanceHAS-A refers to composition or aggregationThe problem with IS-A and HAS-A#2. Use case formatsFocusing on interactionA more formal use case#3. Anti patterns#4. CRC cardsCRC cards help implement the SRP#5. Metrics#6. Sequence diagrams#7. State diagrams#8. Unit testingWhat a test case looks likeTest your code in context#9. Coding standards and readable codeGreat software is more than just working code#10. Refactoring
B. Welcome to Objectville: Speaking the Language of OO
Welcome to ObjectvilleUML and class diagramsNext up: inheritanceAnd polymorphism, too...Last but not least: encapsulationNow anyone can set the speed directlySo what’s the big deal?
Index
About the Authors
Copyright

Content preview from Head First Object-Oriented Analysis and Design

Chapter 9. Iterating and Testing: The Software is Still for the Customer

It’s time to show the customer how much you really care. Nagging bosses? Worried clients? Stakeholders that keep asking, “Will it be done on time?” No amount of well-designed code will please your customers; you’ve got to show them something working. And now that you’ve got a solid OO programming toolkit, it’s time to learn how you can prove to the customer that your software works. In this chapter, we learn about two ways to dive deeper into your software’s functionality, and give the customer that warm feeling in their chest that makes them say, Yes, you’re definitely the right developer for this job!

Your toolbox is filling up

We’ve learned quite a bit so far, and our toolbox of analysis and design tools is getting pretty full. We even added some OO programming techniques in the last chapter:

But you’re still writing your ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition

Craig Larman

Publisher Resources

ISBN: 0596008678Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design