Good software design is essential for the success of your project, but designing software is hard to do. You need to have a deep understanding of the consequences of design decisions and a good overview of available design alternatives. With this book, experienced C++ developers will get a thorough, practical, and unparalleled overview of software design with this modern language.
C++ trainer and consultant Klaus Iglberger explains how you can manage dependencies and abstractions, improve changeability and extensibility of software entities, and apply and implement modern design patterns to help you take advantage of today's possibilities. Software design is the most essential aspect of a software project because it impacts the software's most important properties: maintainability, changeability, and extensibility.
- Learn how to evaluate your code with respect to software design
- Understand what software design is, including design goals such as changeability and extensibility
- Explore the advantages and disadvantages of each design approach
- Learn how design patterns help solve problems and express intent
- Choose the right form of a design pattern to get the most out of its advantages
Author(s): Klaus Iglberger
Edition: 1
Publisher: O'Reilly Media
Year: 2022
Language: English
Commentary: The Table Of Content is broken, all of its links needs to be renamed using ".xhtml" extension instead of the current ".html". The Index is more than broken, it doesn't exists, albeit there is a file for it.
Pages: 427
City: Sebastopol, CA
Tags: C++; Software Design; Design Patterns
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 of Artificial Coupling
Logical Versus 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 of Violating Expectations
The Liskov Substitution Principle
Criticism of 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 Plug-In Architecture
Dependency Inversion via Templates
Dependency Inversion via Overload Sets
Dependency Inversion Principle Versus 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 Not Limited to Object-Oriented Programming or 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 Visitor 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 Visitor
Introduction to std::variant
Refactoring the Drawing of Shapes as a Value-Based, Nonintrusive Solution
Performance Benchmarks
Analyzing the Shortcomings of the std::variant Solution
Guideline 18: Beware the Performance of Acyclic Visitor
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 Command 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 over 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 Versus 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 an 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 Bridge Performance Gains and Losses
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 Nonintrusive 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: Be Aware of the Optimization Potential of Type Erasure
Small Buffer Optimization
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 Nonowning Type Erasure Implementation
A More Powerful Nonowning 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 Trade-off 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 Toward Local Dependency Injection
11. The Last Guideline
Guideline 39: Continue to Learn About Design Patterns
Index
About the Author
