C++ Software Design

Preface
Why I Wrote This Book
What This Book is About
Software Design
Modern C++
Design Patterns
Who This Book Is For
How This Book Is Structured
Conventions Used in This Book
Using Code Examples
O’Reilly Online Learning
How to Contact Us
Acknowledgments

1. The Art of Software Design
Guideline 1: Understand the Importance of Software Design
Features are Not Software Design
Software Design: The Art of Managing Dependencies and Abstractions
The Three Levels of Software Development
The Focus on Features
The Focus on Software Design and Design Principles
Guideline 2: Design for Change
Separation of Concerns
An Example for Artificial Coupling
Logical vs. Physical Coupling
Don’t Repeat Yourself
Avoid Premature Separation of Concerns
Guideline 3: Separate Interfaces to Avoid Artificial Coupling
Segregate Interfaces to Separate Concerns
Minimizing Requirements of Template Arguments
Guideline 4: Design for Testability
How to Test a Private Member Function
The True Solution: Separate Concerns
Guideline 5: Design for Extension
The Open-Closed Principle
Compile-time Extensibility
Avoid Premature Design for Extension

2. The Art of Building Abstractions
Guideline 6: Adhere to the Expected Behavior of Abstractions
An Example for Violating Expectations
The Liskov Substitution Principle
Criticism about the Liskov Substitution Principle
The Need for Good and Meaningful Abstractions
Guideline 7: Understand the Similarities between Base Classes and Concepts
Guideline 8: Understand the Semantic Requirements of Overload Sets
The Power of Free Functions: A Compile-Time Abstraction Mechanism
The Problem of Free Functions: Expectations on the Behavior
Guideline 9: Pay Attention to the Ownership of Abstractions
The Dependency Inversion Principle
Dependency Inversion in a Plugin Architecture
Dependency Inversion via Templates
Dependency Inversion via Overload Sets
Dependency Inversion Principle vs. Single-Responsibility Principle
Guideline 10: Consider Creating an Architectural Document

3. The Purpose of Design Patterns
Guideline 11: Understand the Purpose of Design Patterns
A Design Pattern Has a Name
A Design Pattern Carries an Intent
A Design Pattern Introduces an Abstraction
A Design Pattern Has Been Proven
Guideline 12: Beware of Design Pattern Misconceptions
Design Patterns are not a Goal
Design Patterns are not about Implementation Details
Design Patterns are Neither Limited to Object-Oriented Programming nor Dynamic Polymorphism
Guideline 13: Design Patterns are Everywhere
Guideline 14: Use a Design Pattern’s Name to Communicate Intent

4. The Visitor Design Pattern
Guideline 15: Design for the Addition of Types or Operations
A Procedural Solution
An Object-Oriented Solution
Be Aware of the Design Choice in Dynamic Polymorphism
Guideline 16: Use Visitors to Extend Operations
Analyzing the Design Issues
The Visitor Design Pattern Explained
Analyzing the Shortcomings of the Visitor Design Pattern
Guideline 17: Consider std::variant for Implementing Visitors
Introduction to std::variant
Refactoring the Drawing of Shapes as Value-Based, Non-Intrusive Solution
Performance Benchmarks
Analyzing the Shortcomings of the std::variant Solution
Guideline 18: Beware the Performance of Acyclic Visitors

5. The Strategy and Command Design Patterns
Guideline 19: Use Strategy to Isolate How Things are Done
Analyzing the Design Issues
The Strategy Design Pattern Explained
Analyzing the Shortcomings of the Naive Solution
Comparison between Visitor and Strategy
Analyzing the Shortcomings of the Strategy Design Pattern
Policy-Based Design
Guideline 20: Favor Composition Over Inheritance
Guideline 21: Use Commands to Isolate What Things are Done
The Command Design Pattern Explained
The Command Design Pattern Versus the Strategy Design Pattern
Analyzing the Shortcomings of the Command Design Pattern
Guideline 22: Prefer Value Semantics to Reference Semantics
The Shortcomings of the GoF Style: Reference Semantics
Reference Semantics - A Second Example
The Modern C++ Philosophy: Value Semantics
Value Semantics - A Second Example
Prefer to Use Value Semantics to Implement Design Patterns
Guideline 23: Prefer a Value-Based Implementation of Strategy and Command
Introduction to std::function
Refactoring the Drawing of Shapes
Performance Benchmarks
Analyzing the Shortcomings of the std::function Solution

6. The Adapter, Observer and CRTP Design Patterns
Guideline 24: Use Adapters to Standardize Interfaces
The Adapter Design Pattern Explained
Object Adapters vs. Class Adapters
Examples from the Standard Library
Comparison between Adapter and Strategy
Function Adapters
Analyzing the Shortcomings of the Adapter Design Pattern
Guideline 25: Apply Observers as an Abstract Notification Mechanism
The Observer Design Pattern Explained
A Classic Observer Implementation
An Observer Implementation Based on Value Semantics
Analyzing the Shortcomings of the Observer Design Pattern
Guideline 26: Use CRTP to Introduce Static Type Categories
A Motivation for CRTP
The CRTP Design Pattern Explained
Analyzing the Shortcomings of the CRTP Design Pattern
The Future of CRTP: A Comparison between CRTP and C++20 Concepts
Guideline 27: Use CRTP for Static Mixin Classes
A Strong Type Motivation
Using CRTP As Implementation Pattern

7. The Bridge, Prototype, and External Polymorphism Design Patterns
Guideline 28: Build Bridges to Remove Physical Dependencies
A Motivating Example
The Bridge Design Pattern Explained
The Pimpl Idiom
Comparison between Bridge and Strategy
Analyzing the Shortcomings of the Bridge Design Pattern
Guideline 29: Be Aware of the Performance Gains and Losses of Bridges
The Performance Impact of Bridges
Improving Performance with Partial Bridges
Guideline 30: Apply Prototype for Abstract Copy Operations
A Sheep-ish Example: Copying Animals
The Prototype Design Pattern Explained
Comparison between Prototype and std::variant
Analyzing the Shortcomings of the Prototype Design Pattern
Guideline 31: Use External Polymorphism for Non-Intrusive Runtime Polymorphism
The External Polymorphism Design Pattern Explained
Drawing of Shapes Revisited
Comparison between External Polymorphism and Adapter
Analyzing the Shortcomings of the External Polymorphism Design Pattern

8. The Type Erasure Design Pattern
Guideline 32: Consider Replacing Inheritance Hierarchies with Type Erasure
The History of Type Erasure
The Type Erasure Design Pattern Explained
An Owning Type Erasure Implementation
Analyzing the Shortcomings of the Type Erasure Design Pattern
Comparing two Type Erasure Wrappers
Interface Segregation of Type Erasure Wrappers
Performance Benchmarks
A Word About Terminology
Guideline 33: Know about the Optimization Potential of Type Erasure
Small Buffer Optimization (SBO)
Manual Implementation of Function Dispatch
Guideline 34: Be Aware of the Setup Costs of Owning Type Erasure Wrappers
The Setup Costs of an Owning Type Erasure Wrapper
A Simple Non-Owning Type Erasure Implementation
A More Powerful Non-Owning Type Erasure Implementation

9. The Decorator Design Pattern
Guideline 35: Use Decorators to Add Customization Hierarchically
Your Coworkers’ Design Issue
The Decorator Design Pattern Explained
A Classic Implementation of the Decorator Design Pattern
A Second Decorator Example
Comparison between Decorator, Adapter and Strategy
Analyzing the Shortcomings of the Decorator Design Pattern
Guideline 36: Understand the Tradeoff Between Runtime and Compile Time Abstraction
A Value-Based Compile Time Decorator
A Value-Based Runtime Decorator

10. The Singleton Pattern
Guideline 37: Treat Singleton as an Implementation Pattern, Not a Design Pattern
The Singleton Pattern Explained
Singleton Does Not Manage Or Reduce Dependencies
Guideline 38: Design Singletons for Change and Testability
Singletons Represent Global State
Singletons Impede Changeability and Testability
Inverting the Dependencies on a Singleton
Applying the Strategy Design Pattern
Moving Towards Local Dependency Injection

11. The Last Guideline
Guideline 39: Continue to Learn About Design Patterns

About the Author