[Head First Series 01] • Head First Object-Oriented Analysis and Design by McLaughlin, Brett -- Read -- Imperial Library of Trantor

Index

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

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 like And Inventory.java... But then Rick started losing customers... What’s the FIRST thing you’d change? Great software is... more than just one thing Great software in 3 easy steps Remember Rick? Remember his lost customers? So let’s apply our 3 steps Ditching String comparisons Rick’s 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 Rick’s app... Design once, design twice Let’s 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

You’ve got a new programming gig Todd and Gina: your first customer Let’s 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! Let’s 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, You’re Perfect... Now Change

You’re 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 Let’s 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: I’ll just compare two strings Sam: I’ll delegate bark comparison

Delegation in Sam’s 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 It’s all about the use case There is no Bark class here! One of these things is not like the other...

Focus: owner’s dog Focus: owner’s dog’s bark

Remember: pay attention to those nouns! From good analysis to good classes... Class diagrams dissected Class diagrams aren’t everything So how does recognize() work now?

5. (Part 1) Good Design = Flexible Software: Nothing Ever Stays the Same

Rick’s Guitars Stringed Instruments is expanding Let’s put our design to the test Did you notice that abstract base class? We’ll need a MandolinSpec class, too Behold: Rick’s new application Class diagrams dissected (again) Let’s code Rick’s new search tool Create an abstract class for instrument specifications Let’s code GuitarSpec... ... and MandolinSpec, too Finishing up Rick’s search tool Uh 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 Workout Back to Rick’s 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) Let’s turn some bad design decisions into good ones One more cubicle conversation (and some help from Jill) “Double encapsulation” in Rick’s software Getting dynamic with instrument properties What we did: a closer look Using the new Instrument and InstrumentSpec classes Finishing up Rick’s app: the InstrumentType enum Let’s update Inventory, too Behold: Rick’s flexible application But does the application actually work? Test driving Rick’s well-designed software Rick’s 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 Rick’s software, in review Knowing 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 problem The things you already know... So let’s 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 there’s 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 Let’s do a little domain analysis! What most people give the customer... What we’re giving the customer... Now divide and conquer Don’t forget who your customer really is What’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 architecture Architecture takes a big chaotic mess... ... and helps us turn it into a well-ordered application Let’s 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? We’ve got a lot less chaos now... ... but there’s still plenty left to do Cubicle Argument Conversation The Tile and Unit classes

Keep the right focus

More order, less chaos

We’ve got structure now, too...

Which feature should we work on next? Game-specific units... what does that mean? Commonality revisited Solution #1: It’s all different! Solution #2: It’s 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? It’s “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 Rick’s Stringed Instruments? The OCP, step-by-step Principle #2: The Don’t Repeat Yourself Principle (DRY)

A prime place to apply DRY... 1. Let’s 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

You’ve 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 you’re still writing your software for the CUSTOMER! Iterating deeper: two basic choices Feature driven development Use case driven development Two approaches to development

What’s the difference between feature driven and use case driven development?

Let’s 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...

Let’s go with the commonality-focused solution Match your tests to your design Let’s write the Unit class Test cases dissected... Prove yourself to the customer We’ve 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 don’t trust your users... -or if they don’t trust you... Moving units

Haven’t 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 you’re 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...

Let’s take a look at that subway file Let’s 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 Java’s default equals() implementation does... What our equals() implementation does...

Protecting your classes (and your client’s classes, too) The SubwayLoader class It’s time to iterate again But 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 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 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-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 what’s the big deal?

Index About the Authors Copyright

← Prev
Back
Next →

← Prev
Back
Next →