C++ Software Design
Published on 21. September 2022
438 pages
978-1-0981-1313-1 (ISBN)
Description
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
More details
Other editions
Additional editions
Book
10/2022
O'Reilly
€79.50
Available immediately
Content
- Cover
- Copyright
- Table of Contents
- 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
- Chapter 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
- Chapter 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
- Chapter 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
- Chapter 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
- Chapter 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
- Chapter 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
- Chapter 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
- Chapter 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
- Chapter 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
- Chapter 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
- Chapter 11. The Last Guideline
- Guideline 39: Continue to Learn About Design Patterns
- Index
- About the Author
- Colophon
