Head First Object-Oriented Analysis and Design

by McLaughlin, Brett

• ISBN13: 9780596008673
• ISBN10: 0596008678
• Format: Paperback
• Copyright: 2006-11-01
• Publisher: Oreilly & Associates Inc

Summary

Packed with attention-grabbing graphics, illustrations, cartoons, and photos "Head First Objects" offers a complete introduction to Object-Oriented programming for experienced programmers new to the methodology and even those new to programming. The book builds knowledge in an engaging style that loads information in the reader's brain in a way that works. The latest research in cognitive science, neurobiology, and educational psychology shows that learning takes a lot more than just text on a page. Combining words and pictures not only helps readers understand a subject, but also to remember it. The book starts with the fundamentals and moves on cover the gamut of object-oriented concepts and design principles.

Author Biography

Brett McLaughlin is a bestselling and award-winning non-fiction author. His books on computer programming, home theater, and analysis and design have sold in excess of 100,000 copies. He has been writing, editing, and producing technical books for nearly a decade, and is as comfortable in front of a word processor as he is behind a guitar, chasing his two sons and his daughter around the house, or laughing at reruns of Arrested Development with his wife.

Brett spends most of his time these days on cognitive theory, codifying and expanding on the learning principles that shaped the Head First series into a bestselling phenomenon. He's curious about how humans best learn, why Star Wars was so formulaic and still so successful, and is adamant that a good video game is the most effective learning paradigm we have.

Gary Pollice is a self-labeled curmudgeon (that's a crusty, ill- tempered, usually old man) who spent over 35 years in industry trying to figure out what he wanted to be when he grew up. Even though he hasn't grown up yet, he did make the move in 2003 to the hallowed halls of academia where he has been corrupting the minds of the next generation of software developers with radical ideas like, "develop software for your customer, learn how to work as part of a team, design and code quality and elegance and correctness counts, and it's okay to be a nerd as long as you are a great one." Gary is also a co-author of Head First Object-Oriented Analysis and Design. Gary is a Professor of Practice (meaning he had a real job before becoming a professor) at Worcester Polytechnic Institute. He went to WPI because he was so impressed with the WPI graduates that he's worked with over the years. He lives in central Massachusetts with his wife, Vikki, and their two dogs, Aloysius and Ignatius. When not working on geeky things he ... well he's always working on geeky things. You can see what he's up to by visiting his WPI home page at http://web.cs.wpi.edu/~gpollice/. Feel free to drop him a note and complain or cheer about the book.

David West would like to describe himself as sheik geek. Unfortunately no one else would describe him in that way. They would say he is a professional Englishman who likes to talk about software development best practices with the passion and energy of an evangelical preacher. Recently Dave has moved to Ivar Jacobson Consulting, where he runs the Americas and can combine his desire to talk about software development and spread the word on rugby and football, and argue that cricket is more exciting that baseball. Before running the Americas for Ivar Jacobson Consulting, Dave worked for a number of years at Rational Software (now a part of IBM). Dave held many positions at Rational and then IBM, including Product Manager for RUP where he introduced the idea of process plug-ins and agility to RUP. Dave still laments the days when he use to sit in a cube and write software in the city of London. This is where he believes he cut his teeth writing big insurance systems with nothing but a green screen and a process flow chart.

Dave can be contacted at [e-mail], and if he is not with customers or drinking warm beer with his friends in Boston, he will email you back.

Table of Contents

Who is this book for?	xxiv
We know what you're thinking	xxv
Metacognition	xxvii
Bend your brain into submission	xxix
Read Me	xxx
The Technical Team	xxxii
Acknowledgements	xxxiii
Great Software Begins Here
Rock and roll is forever!	2	(1)
Rick's shiny new application	3	(5)
What's the First thing you'd change?	8	(2)
Great Software is...	10	(3)
Great software in 3 easy steps	13	(5)
Focus on functionality first	18	(5)
Test drive	23	(2)
Looking for problems	25	(1)
Analysis	26	(5)
Apply basic OO principles	31	(5)
Design once, design twice	36	(2)
How easy is it to change your applications?	38	(3)
Encapsulate what varies	41	(2)
Delegation	43	(3)
Great software at last (for now)	46	(3)
OOA&D is about writing great software	49	(1)
Bullet Points	50	(6)
Give Them What They Want
You've got a new programming gig	56	(3)
Test drive	59	(2)
Incorrect usage (sort of)	61	(1)
What is a requirement?	62	(2)
Creating a requirements list	64	(4)
Plan for things going wrong	68	(2)
Alternate paths handle system problems	70	(2)
Introducing use cases	72	(2)
One use case, three parts	74	(4)
Check your requirements against your use cases	78	(7)
Your system must work in the real world	85	(7)
Getting to know the Happy Path	92	(14)
OOA&D Toolbox	106	(6)
I Love You, You're Perfect... Now Change
You're a hero!	112	(1)
You're a goat!	113	(2)
The one constant in software analysis & design	115	(5)
Original path? Alternate path? Who can tell?	120	(2)
Use cases have to make sense to you	122	(2)
Start to finish: a single scenario	124	(2)
Confessions of an Alternate Path	126	(4)
Finishing up the requirements list	130	(8)
Duplicate code is a bad idea	138	(2)
Final test drive	140	(1)
Write your own design principle	141	(1)
OOA&D Toolbox	142	(4)
Taking Your Software into the Real World
One dog, two dog, three dog, four...	146	(1)
Your software has a context	147	(1)
Identify the problem	148	(1)
Plan a solution	149	(7)
A tale of two coders	156	(4)
Delegation Detour	160	(2)
The power of loosely coupled applications	162	(5)
Pay attention to the nouns in your use case	167	(13)
From good analysis to good classes...	180	(2)
Class diagrams dissected	182	(5)
Class diagrams aren't everything	187	(4)
Bullet Points	191	(7)
(Part 1) Nothing Ever Stays the Same
Rick's Guitars is expanding	198	(3)
Abstract classes	201	(5)
Class diagrams dissected (again)	206	(1)
UML Cheat Sheet	207	(6)
Design problem tipoffs	213	(2)
3 steps to great software (revisited)	215	(19)
(part 2) Give Your Software a 30-minute Workout
Back to Rick's search tool	234	(3)
A closer look at the search() method	237	(1)
The benefits of analysis	238	(3)
Classes are about behavior	241	(5)
Death of a design (decision)	246	(1)
Turn bad design decisions into good ones	247	(2)
``Double encapsulation'' in Rick's software	249	(6)
Never be afraid to make mistakes	255	(3)
Rick's flexible application	258	(3)
Test driving well-designed software	261	(4)
How easy is it to change Rick's software?	265	(1)
The Great Ease-of-Change Challenge	266	(3)
A cohesive class does one thing really well	269	(3)
The design/cohesion lifecycle	272	(2)
Great software is ``good enough''	274	(2)
OOA&D Toolbox	276	(4)
``My Name is Art Vandelay... I am an Architect''
Solving big problems	280	(1)
It's all in how you look at the big problem	281	(5)
Requirements and use cases are a good place to start...	286	(1)
Commonality and variability	287	(3)
Figure out the features	290	(2)
The difference between features and requirements	292	(2)
Use cases don't always help you see the big picture	294	(2)
Use case diagrams	296	(5)
The Little Actor	301	(1)
Actors are people, too (well, not always)	302	(5)
Let's do a little domain analysis	307	(2)
Divide and conquer	309	(4)
Don't forget who the customer really is	313	(2)
What's a design pattern?	315	(3)
The power of OOA&D (and a little common sense)	318	(2)
OOA&D Toolbox	320	(4)
Bringing Order to Chaos
Feeling a little overwhelmed?	324	(2)
We need an architecture	326	(3)
Start with functionality	329	(2)
What's architecturally significant?	331	(1)
The three Qs of architecture	332	(6)
Reducing risk	338	(3)
Scenarios help reduce risk	341	(8)
Focus on one feature at a time	349	(2)
Architecture is your design structure	351	(4)
Commonality revisited	355	(6)
Commonality Analysis: the path to flexible software	361	(5)
What does it mean? Ask the customer	366	(5)
Reducing risk helps you write great software	371	(1)
Bullet Points	372	(4)
Originality is Overrated
Design principle roundup	376	(1)
The Open-Closed Principle (OCP)	377	(2)
The OCP, step-by-step	379	(3)
The Don't Repeat Yourself Principle (DRY)	382	(2)
DRY is about one requirement in one place	384	(6)
The Single Responsibility Principle (SRP)	390	(2)
Spotting multiple responsibilities	392	(3)
Going from multiple responsibilities to a single responsibility	395	(5)
The Liskov Substitution Principle (LSP)	400	(1)
Misusing subclassing: a case study in in misuing inheritance	401	(1)
LSP reveals hidden problems with your inheritance structure	402	(1)
Subtypes must be substitutable for their base types	403	(1)
Violating the LSP makes for confusing code	404	(2)
Delegate functionality to another class	406	(2)
Use composition to assemble behaviors from other classes	408	(4)
Aggregation: composition, without the abrupt ending	412	(1)
Aggregation versus composition	413	(1)
Inheritance is just one option	414	(3)
Bullet Points	417	(1)
OOA&D Toolbox	418	(6)
The Software is Still for the Customer
Your toolbox is filling up	424	(2)
You write great software iteratively	426	(1)
Iterating deeper: two basic choices	427	(1)
Feature driven development	428	(1)
Use case driven development	429	(1)
Two approaches to development	430	(4)
Analysis of a feature	434	(3)
Writing test scenarios	437	(3)
Test driven development	440	(2)
Commonality Analysis (redux)	442	(4)
Emphasizing commonality	446	(2)
Emphasizing encapsulation	448	(4)
Match your tests to your design	452	(2)
Test cases dissected...	454	(6)
Prove yourself to the customer	460	(2)
We've been programming by contract	462	(1)
Programming by contract is about trust	463	(1)
Defensive programming	464	(9)
Break your apps into smaller chunks of functionality	473	(2)
Bullet Points	475	(3)
OOA&D Toolbox	478	(6)
Putting It All Together
Developing software, OOA&D style	484	(4)
The Objectville Subway problem	488	(2)
Objectville Subway Map	490	(3)
Feature lists	493	(6)
Use cases reflect usage, features reflect functionality	499	(4)
Now start to iterate	503	(2)
A closer look at representing a subway	505	(9)
To use a Line, or not to use a Line	514	(6)
Points of interest on the Objectville Subway (class)	520	(3)
Protecting your classes	523	(8)
Break time	531	(2)
Back to the requirements phase	533	(2)
Focus on code, then focus on customers	535	(4)
Iteration makes problems easier	539	(5)
What does a route look like?	544	(4)
Check out Objectville for yourself!	548	(3)
Iteration #3, anyone?	551	(4)
The journey's not over...	555	(3)
The Top Ten Topics (we didn't cover)
IS-A and HAS-A	558	(2)
Use case formats	560	(3)
Anti-patterns	563	(1)
CRC cards	564	(2)
Metrics	566	(1)
Sequence diagrams	567	(1)
State diagrams	568	(2)
Unit testing	570	(2)
Coding standards and readable code	572	(2)
Refactoring	574	(3)
Speaking the Language of OO
UML and class diagrams	577	(2)
Inheritance	579	(2)
Polymorphism	581	(1)
Encapsulation	582	(4)
Bullet Points	586