Object Oriented Software Design in C++ MEAP 1st Edition by Ronald Mak ISBN 9781633439504 163343950X

Part 1. Introduction

1 The path to well-designed software

1.1 What is software design?

1.2 What you will learn from this book

1.3 The benefits of good software design

1.4 A few design examples

1.4.1 Leaking changes

1.4.2 Code that’s too complex

1.4.3 Inflexible code

1.4.4 Surprise!

1.4.5 Common architecture problems

1.5 Make sure we’re going to build the right application; then, build it right

1.6 Good design doesn’t come easily

1.7 Change and complexity are the enemies of good design

1.8 Design with object-oriented programming concepts

Summary

2 Iterate to achieve good design

2.1 Good application design requires an iterative process

2.2 Don’t let changes leak out

2.3 Iterate to achieve good design

2.3.1 Iteration 1: Initial cohesive classes

2.3.2 Iteration 2: Encapsulation, delegation, and loose coupling

2.3.3 Iteration 3: More kinds of books and their attributes

2.3.4 Iteration 4: A better design after backtracking

Summary

Part 2. Design the right application

3 Get requirements to build the right application

3.1 The overture to application design

3.2 Functional requirements: What must the application do?

3.3 Nonfunctional requirements: Constraints on the application

3.4 What are good requirements?

3.5 How to get requirements

3.5.1 A short requirements case study

3.5.2 Stated and implied requirements

3.6 Unified Modeling Language diagrams for creating and documenting design

3.7 Use cases provide context for the requirements

3.7.1 UML use case diagram

3.7.2 Use case description

3.8 The functional specification and software validation

3.9 Where do classes come from?

3.9.1 Textual analysis: Nouns can become classes

3.9.2 Textual analysis: Verbs can become member functions

Summary

4 Good class design to build the application right

4.1 When do we do application design?

4.2 Two important goals for good class design

4.2.1 Cohesion and the Single Responsibility Principle

4.2.2 Loose coupling and the Principle of Least Knowledge

4.3 UML class diagrams to document class design

4.4 Class relationships determine runtime interactions

4.4.1 Dependency: The most basic relationship

4.4.2 Aggregation and composition: Objects that contain other objects

4.4.3 Generalization: Superclasses and their subclasses

4.4.4 Abstract classes and interfaces: What subclasses must implement

4.5 UML state diagram: How an object changes state

4.6 UML sequence diagram: How objects interact [optional]

4.7 The design specification and software verification

Summary

Part 3. Design the application right

5 Hide class implementations

5.1 The Principle of Least Knowledge and hidden implementations

5.2 Public getter and setter functions access hidden implementation selectively

5.3 Class Date: An example of implementation hiding

5.3.1 Iteration 1: Date arithmetic with loops

5.3.2 Iteration 2: Julian day numbers simplify date arithmetic

5.3.3 Iteration 3: A hybrid approach with lazy evaluation

5.4 Public setter functions carefully modify hidden implementation

5.5 Beware of dangerous setter functions

5.6 Rules from the Law of Demeter

5.7 But is the implementation really hidden?

5.8 The Open-Closed Principle supports code stability

Summary

6 Don’t surprise your users

6.1 No surprises and the Principle of Least Astonishment

6.1.1 Off-by-one errors

6.1.2 Misnamed functions can mislead their callers

6.2 Poor performance is an unwelcome surprise

6.2.1 Bad design can cause unexpected performance problems

6.2.2 The vexatious performance of C++ vectors

6.3 Programming by Contract helps to eliminate surprises [optional]

6.3.1 Programming a circular buffer by contract

6.3.2 Precondition: What must be true before calling a function

6.3.3 Postcondition: What must be true after returning from a function

6.3.4 Class invariant: What must remain true of object states

Summary

7 Design subclasses right

7.1 When to use function overriding or overloading

7.1.1 Override superclass member functions to get subclass behavior

7.1.2 Overload functions that have similar or equivalent behaviors

7.2 The Liskov Substitution Principle and proper subclasses

7.3 Choosing the is-a and has-a relationships

7.4 Use a factory function with the Code to the Interface Principle

7.5 Programming by Contract with subclasses [optional]

Summary

Part 4. Design patterns solve application architecture problems

The benefits of design patterns

Explaining the design patterns

The sports examples

8 The Template Method and Strategy Design Patterns

8.1 The Template Method Design Pattern defines the steps of an algorithm

8.1.1 Desired design features

8.1.2 Before using the Template Method Design Pattern

8.1.3 After using the Template Method Design Pattern

8.1.4 Template Method’s generic model

8.2 The Strategy Design Pattern encapsulates algorithms

8.2.1 Desired design features

8.2.2 Before using the Strategy Design Pattern

8.2.3 After using the Strategy Design Pattern

8.2.4 Strategy’s generic model

8.3 Choose between Template Method and Strategy

Summary

9 The Factory Method and Abstract Factory Design Patterns

9.1 The Factory Method Design Pattern lets subclasses create objects

9.1.1 Desired design features

9.1.2 Before using the Factory Method Design Pattern

9.1.3 After using the Factory Method Design Pattern

9.1.4 Factory Method’s generic model

9.2 The Abstract Factory Design Pattern creates families of objects

9.2.1 Before using the Abstract Factory Design Pattern

9.2.2 After using the Abstract Factory Design Pattern

9.2.3 Abstract Factory’s generic model

Summary

10 The Adapter and Façade Design Patterns

10.1 The Adapter Design Pattern integrates code

10.1.1 Desired design features

10.1.2 Before using the Adapter Design Pattern

10.1.3 After using the Adapter Design Pattern

10.1.4 Adapter’s generic model

10.1.5 An alternative Adapter Design Pattern model

10.2 The Façade Design Pattern hides a subsystem of interfaces

10.2.1 Desired design features

10.2.2 Before using the Façade Design Pattern

10.2.3 After using the Façade Design Pattern

10.2.4 Façade’s generic model

Summary

11 The Iterator and Visitor Design Patterns

11.1 The Iterator Design Pattern encapsulates iterating over different sequential collections

11.1.1 Desired design features

11.1.2 Before using the Iterator Design Pattern

11.1.3 After using the Iterator Design Pattern

11.1.4 Iterator’s generic model

11.2 The Visitor Design Pattern encapsulates different algorithms that operate on a data collection

11.2.1 Desired design features

11.2.2 Before using the Visitor Design Pattern

11.3 After using the Visitor Design Pattern

11.3.1 Visitor’s generic model

Summary

12 The Observer Design Pattern

12.1 The Observer Design Pattern represents the publisher–subscriber model

12.1.1 Desired design features

12.1.2 Before using the Observer Design Pattern

12.1.3 After using the Observer Design Pattern

12.1.4 The Observer’s generic model

Summary

13 The State Design Pattern

13.1 The State Design Pattern models state transitions

13.1.1 Desired design features

13.1.2 Before using the State Design Pattern

13.1.3 After using the State Design Pattern

13.1.4 State’s generic model

Summary

14 The Singleton, Composite, and Decorator Design Patterns

14.1 The Singleton Design Pattern ensures a class has only one object

14.1.1 Desired design features

14.1.2 Before using the Singleton Design Pattern

14.1.3 After using the Singleton Design Pattern

14.1.4 Singleton’s generic model

14.2 The Composite Design Pattern treats individual and composite objects uniformly

14.2.1 Desired design features

14.2.2 Before using the Composite Design Pattern

14.2.3 After using the Composite Design Pattern

14.2.4 Composite’s generic model

14.3 The Decorator Design Pattern dynamically adds object responsibilities

14.3.1 Desired design features

14.3.2 Before using the Decorator Design Pattern

14.3.3 After using the Decorator Design Pattern

14.3.4 Decorator’s generic model

Summary

Part 5. Additional Design Techniques

15 Designing solutions with recursion and backtracking

15.1 Recursion compared to the for loop

15.2 Finding the largest value by recursion

15.3 Reversing a vector by recursion

15.4 Solve the Towers of Hanoi puzzle by recursion

15.5 Recursive algorithms for a binary search tree

15.5.1 Inserting into a BST with recursion

15.5.2 Printing a BST with recursion

15.5.3 Removing all the nodes of a BST with recursion

15.6 Quicksort an array with recursion

15.6.1 Quicksort in action

15.6.2 Partitioning an array into subarrays

15.6.3 Quicksort implementation

15.7 The Fibonacci sequence and a recursion disaster

15.8 Dynamic backtracking increases the power of recursion

15.9 Solving the eight queens puzzle with recursion and backtracking

15.10 Solving Sudoku puzzles with recursion and backtracking

Summary

16 Designing multithreaded programs

16.1 How do things happen simultaneously?

16.2 A mutex enforces mutual exclusion

16.2.1 Protect the integrity of a shared resource

16.2.2 The classic reader–writer problem

16.3 Condition variables synchronize threads

16.3.1 How condition variables synchronize threads

16.3.2 The classic producer–consumer problem

16.4 A final note on multithreading

Summary

index