Cantitate/Preț
Produs

Head First Object–Oriented Analysis and Design

De (autor) , ,
Notă GoodReads:
en Limba Engleză Paperback – 05 Dec 2006
Shows you how to analyze, design, and write serious object-oriented software. This work helps you learn how to: use OO principles like encapsulation and delegation to build applications that are flexible; apply the Open-Closed Principle (OCP) and the Single Responsibility Principle (SRP) to promote reuse of your code; among others.
Citește tot Restrânge

Preț: 30764 lei

Preț vechi: 35361 lei
-13%

Puncte Express: 461

Preț estimativ în valută:
5957 6256$ 5138£

Carte disponibilă

Livrare economică 19-24 decembrie
Livrare express 15-21 decembrie pentru 5331 lei

Preluare comenzi: 021 569.72.76

Specificații

ISBN-13: 9780596008673
ISBN-10: 0596008678
Pagini: 634
Dimensiuni: 203 x 233 x 32 mm
Greutate: 1.2 kg
Editura: O'Reilly
Locul publicării: United States

Cuprins

;
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;
Chapter 1: Well-Designed Apps Rock: Great Software Begins Here;
1.1 Rock and roll is forever!;
1.2 Rick's shiny new application...;
1.3 Here what the code for Guitar.java looks like;
1.4 And Inventory.java...;
1.5 But then Rick started losing customers...;
1.6 What's the FIRST thing you'd change?;
1.7 Great software is... more than just one thing;
1.8 Great software in 3 easy steps;
1.9 Remember Rick? Remember his lost customers?;
1.10 So let's apply our 3 steps;
1.11 Ditching String comparisons;
1.12 Rick's customers want choices!;
1.13 Test drive;
1.14 Back to our steps;
1.15 Looking for problems;
1.16 Analyze the search() method;
1.17 Now update your own code;
1.18 Update the Inventory class;
1.19 Getting ready for another test drive;
1.20 Getting back to Rick's app...;
1.21 Design once, design twice;
1.22 Let's make sure Inventory.java is (really) well-designed;
1.23 One last test drive (and an app ready for reuse);
1.24 What we did;
1.25 Remember this poor guy?;
1.26 OOA&D is about writing great software, not doing a bunch of paperwork!;
Chapter 2: Gathering Requirements: Give Them What They Want;
2.1 You've got a new programming gig;
2.2 Todd and Gina: your first customer;
2.3 Let's start with the dog door;
2.4 Test drive;
2.5 But when Gina tried it...;
2.6 Listen to the customer;
2.7 Creating a requirements list;
2.8 What does the dog door really need to do?;
2.9 Plan for things going wrong;
2.10 Alternate paths handle system problems;
2.11 (Re) introducing use cases;
2.12 One use case, three parts;
2.13 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?;