Practical Object-Oriented Design: Practical Object-Oriented Design in Ruby. 2 Ed

 CoverHalf TitleTitle PageCopyright PageDedicationContentsIntroductionAcknowledgmentsAbout the Author1 Object-Oriented Design1.1 In Praise of Design1.1.1 The Problem Design Solves1.1.2 Why Change Is Hard1.1.3 A Practical Definition of Design1.2 The Tools of Design1.2.1 Design Principles1.2.2 Design Patterns1.3 The Act of Design1.3.1 How Design Fails1.3.2 When to Design1.3.3 Judging Design1.4 A Brief Introduction to Object-Oriented Programming1.4.1 Procedural Languages1.4.2 Object-Oriented Languages1.5 Summary2 Designing Classes with a Single Responsibility2.1 Deciding What Belongs in a Class2.1.1 Grouping Methods into Classes2.1.2 Organizing Code to Allow for Easy Changes2.2 Creating Classes That Have a Single Responsibility2.2.1 An Example Application: Bicycles and Gears2.2.2 Why Single Responsibility Matters2.2.3 Determining If a Class Has a Single Responsibility2.2.4 Determining When to Make Design Decisions2.3 Writing Code That Embraces Change2.3.1 Depend on Behavior, Not Data2.3.2 Enforce Single Responsibility Everywhere2.4 Finally, the Real Wheel2.5 Summary3 Managing Dependencies3.1 Understanding Dependencies3.1.1 Recognizing Dependencies3.1.2 Coupling Between Objects (CBO)3.1.3 Other Dependencies3.2 Writing Loosely Coupled Code3.2.1 Inject Dependencies3.2.2 Isolate Dependencies3.2.3 Remove Argument-Order Dependencies3.3 Managing Dependency Direction3.3.1 Reversing Dependencies3.3.2 Choosing Dependency Direction3.4 Summary4 Creating Flexible Interfaces4.1 Understanding Interfaces4.2 Defining Interfaces4.2.1 Public Interfaces4.2.2 Private Interfaces4.2.3 Responsibilities, Dependencies, and Interfaces4.3 Finding the Public Interface4.3.1 An Example Application: Bicycle Touring Company4.3.2 Constructing an Intention4.3.3 Using Sequence Diagrams4.3.4 Asking for “What” Instead of Telling “How”4.3.5 Seeking Context Independence4.3.6 Trusting Other Objects4.3.7 Using Messages to Discover Objects4.3.8 Creating a Message-Based Application4.4 Writing Code That Puts Its Best (Inter)Face Forward4.4.1 Create Explicit Interfaces4.4.2 Honor the Public Interfaces of Others4.4.3 Exercise Caution When Depending on Private Interfaces4.4.4 Minimize Context4.5 The Law of Demeter4.5.1 Defining Demeter4.5.2 Consequences of Violations4.5.3 Avoiding Violations4.5.4 Listening to Demeter4.6 Summary5 Reducing Costs with Duck Typing5.1 Understanding Duck Typing5.1.1 Overlooking the Duck5.1.2 Compounding the Problem5.1.3 Finding the Duck5.1.4 Consequences of Duck Typing5.2 Writing Code That Relies on Ducks5.2.1 Recognizing Hidden Ducks5.2.2 Placing Trust in Your Ducks5.2.3 Documenting Duck Types5.2.4 Sharing Code between Ducks5.2.5 Choosing Your Ducks Wisely5.3 Conquering a Fear of Duck Typing5.3.1 Subverting Duck Types with Static Typing5.3.2 Static versus Dynamic Typing5.3.3 Embracing Dynamic Typing5.4 Summary6 Acquiring Behavior through Inheritance6.1 Understanding Classical Inheritance6.2 Recognizing Where to Use Inheritance6.2.1 Starting with a Concrete Class6.2.2 Embedding Multiple Types6.2.3 Finding the Embedded Types6.2.4 Choosing Inheritance6.2.5 Drawing Inheritance Relationships6.3 Misapplying Inheritance6.4 Finding the Abstraction6.4.1 Creating an Abstract Superclass6.4.2 Promoting Abstract Behavior6.4.3 Separating Abstract from Concrete6.4.4 Using the Template Method Pattern6.4.5 Implementing Every Template Method6.5 Managing Coupling between Superclasses and Subclasses6.5.1 Understanding Coupling6.5.2 Decoupling Subclasses Using Hook Messages6.6 Summary7 Sharing Role Behavior with Modules7.1 Understanding Roles7.1.1 Finding Roles7.1.2 Organizing Responsibilities7.1.3 Removing Unnecessary Dependencies7.1.4 Writing the Concrete Code7.1.5 Extracting the Abstraction7.1.6 Looking Up Methods7.1.7 Inheriting Role Behavior7.2 Writing Inheritable Code7.2.1 Recognize the Antipatterns7.2.2 Insist on the Abstraction7.2.3 Honor the Contract7.2.4 Use the Template Method Pattern7.2.5 Preemptively Decouple Classes7.2.6 Create Shallow Hierarchies7.3 Summary8 Combining Objects with Composition8.1 Composing a Bicycle of Parts8.1.1 Updating the Bicycle Class8.1.2 Creating a Parts Hierarchy8.2 Composing the Parts Object8.2.1 Creating a Part8.2.2 Making the Parts Object More Like an Array8.3 Manufacturing Parts8.3.1 Creating the PartsFactory8.3.2 Leveraging the PartsFactory8.4 The Composed Bicycle8.5 Deciding between Inheritance and Composition8.5.1 Accepting the Consequences of Inheritance8.5.2 Accepting the Consequences of Composition8.5.3 Choosing Relationships8.6 Summary9 Designing Cost-Effective Tests9.1 Intentional Testing9.1.1 Knowing Your Intentions9.1.2 Knowing What to Test9.1.3 Knowing When to Test9.1.4 Knowing How to Test9.2 Testing Incoming Messages9.2.1 Deleting Unused Interfaces9.2.2 Proving the Public Interface9.2.3 Isolating the Object under Test9.2.4 Injecting Dependencies Using Classes9.2.5 Injecting Dependencies as Roles9.3 Testing Private Methods9.3.1 Ignoring Private Methods during Tests9.3.2 Removing Private Methods from the Class under Test9.3.3 Choosing to Test a Private Method9.4 Testing Outgoing Messages9.4.1 Ignoring Query Messages9.4.2 Proving Command Messages9.5 Testing Duck Types9.5.1 Testing Roles9.5.2 Using Role Tests to Validate Doubles9.6 Testing Inherited Code9.6.1 Specifying the Inherited Interface9.6.2 Specifying Subclass Responsibilities9.6.3 Testing Unique Behavior9.7 SummaryAfterwordIndex