book

C++ Software Design

by Klaus Iglberger

September 2022

Intermediate to advanced

438 pages

10h 45m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Includes

Has Sandbox

Why I Wrote This BookWhat This Book Is AboutSoftware DesignModern C++Design PatternsWho This Book Is ForHow This Book Is StructuredConventions Used in This BookUsing Code ExamplesO’Reilly Online LearningHow to Contact UsAcknowledgments
Guideline 1: Understand the Importance of Software DesignFeatures Are Not Software DesignSoftware Design: The Art of Managing Dependencies and AbstractionsThe Three Levels of Software DevelopmentThe Focus on FeaturesThe Focus on Software Design and Design PrinciplesGuideline 2: Design for ChangeSeparation of ConcernsAn Example of Artificial CouplingLogical Versus Physical CouplingDon’t Repeat YourselfAvoid Premature Separation of ConcernsGuideline 3: Separate Interfaces to Avoid Artificial CouplingSegregate Interfaces to Separate ConcernsMinimizing Requirements of Template ArgumentsGuideline 4: Design for TestabilityHow to Test a Private Member FunctionThe True Solution: Separate ConcernsGuideline 5: Design for ExtensionThe Open-Closed PrincipleCompile-Time ExtensibilityAvoid Premature Design for Extension
Guideline 6: Adhere to the Expected Behavior of AbstractionsAn Example of Violating ExpectationsThe Liskov Substitution PrincipleCriticism of the Liskov Substitution PrincipleThe Need for Good and Meaningful AbstractionsGuideline 7: Understand the Similarities Between Base Classes and ConceptsGuideline 8: Understand the Semantic Requirements of Overload SetsThe Power of Free Functions: A Compile-Time Abstraction MechanismThe Problem of Free Functions: Expectations on the BehaviorGuideline 9: Pay Attention to the Ownership of AbstractionsThe Dependency Inversion PrincipleDependency Inversion in a Plug-In ArchitectureDependency Inversion via TemplatesDependency Inversion via Overload SetsDependency Inversion Principle Versus Single-Responsibility PrincipleGuideline 10: Consider Creating an Architectural Document
Guideline 11: Understand the Purpose of Design PatternsA Design Pattern Has a NameA Design Pattern Carries an IntentA Design Pattern Introduces an AbstractionA Design Pattern Has Been ProvenGuideline 12: Beware of Design Pattern MisconceptionsDesign Patterns Are Not a GoalDesign Patterns Are Not About Implementation DetailsDesign Patterns Are Not Limited to Object-Oriented Programming or Dynamic PolymorphismGuideline 13: Design Patterns Are EverywhereGuideline 14: Use a Design Pattern’s Name to Communicate Intent
Guideline 15: Design for the Addition of Types or OperationsA Procedural SolutionAn Object-Oriented SolutionBe Aware of the Design Choice in Dynamic PolymorphismGuideline 16: Use Visitor to Extend OperationsAnalyzing the Design IssuesThe Visitor Design Pattern ExplainedAnalyzing the Shortcomings of the Visitor Design PatternGuideline 17: Consider std::variant for Implementing VisitorIntroduction to std::variantRefactoring the Drawing of Shapes as a Value-Based, Nonintrusive SolutionPerformance BenchmarksAnalyzing the Shortcomings of the std::variant SolutionGuideline 18: Beware the Performance of Acyclic Visitor
Guideline 19: Use Strategy to Isolate How Things Are DoneAnalyzing the Design IssuesThe Strategy Design Pattern ExplainedAnalyzing the Shortcomings of the Naive SolutionComparison Between Visitor and StrategyAnalyzing the Shortcomings of the Strategy Design PatternPolicy-Based DesignGuideline 20: Favor Composition over InheritanceGuideline 21: Use Command to Isolate What Things Are DoneThe Command Design Pattern ExplainedThe Command Design Pattern Versus the Strategy Design PatternAnalyzing the Shortcomings of the Command Design PatternGuideline 22: Prefer Value Semantics over Reference SemanticsThe Shortcomings of the GoF Style: Reference SemanticsReference Semantics: A Second ExampleThe Modern C++ Philosophy: Value SemanticsValue Semantics: A Second ExamplePrefer to Use Value Semantics to Implement Design PatternsGuideline 23: Prefer a Value-Based Implementation of Strategy and CommandIntroduction to std::functionRefactoring the Drawing of ShapesPerformance BenchmarksAnalyzing the Shortcomings of the std::function Solution
Guideline 24: Use Adapters to Standardize InterfacesThe Adapter Design Pattern ExplainedObject Adapters Versus Class AdaptersExamples from the Standard LibraryComparison Between Adapter and StrategyFunction AdaptersAnalyzing the Shortcomings of the Adapter Design PatternGuideline 25: Apply Observers as an Abstract Notification MechanismThe Observer Design Pattern ExplainedA Classic Observer ImplementationAn Observer Implementation Based on Value SemanticsAnalyzing the Shortcomings of the Observer Design PatternGuideline 26: Use CRTP to Introduce Static Type CategoriesA Motivation for CRTPThe CRTP Design Pattern ExplainedAnalyzing the Shortcomings of the CRTP Design PatternThe Future of CRTP: A Comparison Between CRTP and C++20 ConceptsGuideline 27: Use CRTP for Static Mixin ClassesA Strong Type MotivationUsing CRTP as an Implementation Pattern
Guideline 28: Build Bridges to Remove Physical DependenciesA Motivating ExampleThe Bridge Design Pattern ExplainedThe Pimpl IdiomComparison Between Bridge and StrategyAnalyzing the Shortcomings of the Bridge Design PatternGuideline 29: Be Aware of Bridge Performance Gains and LossesThe Performance Impact of BridgesImproving Performance with Partial BridgesGuideline 30: Apply Prototype for Abstract Copy OperationsA Sheep-ish Example: Copying AnimalsThe Prototype Design Pattern ExplainedComparison Between Prototype and std::variantAnalyzing the Shortcomings of the Prototype Design PatternGuideline 31: Use External Polymorphism for Nonintrusive Runtime PolymorphismThe External Polymorphism Design Pattern ExplainedDrawing of Shapes RevisitedComparison Between External Polymorphism and AdapterAnalyzing the Shortcomings of the External Polymorphism Design Pattern
Guideline 32: Consider Replacing Inheritance Hierarchies with Type ErasureThe History of Type ErasureThe Type Erasure Design Pattern ExplainedAn Owning Type Erasure ImplementationAnalyzing the Shortcomings of the Type Erasure Design PatternComparing Two Type Erasure WrappersInterface Segregation of Type Erasure WrappersPerformance BenchmarksA Word About TerminologyGuideline 33: Be Aware of the Optimization Potential of Type ErasureSmall Buffer OptimizationManual Implementation of Function DispatchGuideline 34: Be Aware of the Setup Costs of Owning Type Erasure WrappersThe Setup Costs of an Owning Type Erasure WrapperA Simple Nonowning Type Erasure ImplementationA More Powerful Nonowning Type Erasure Implementation
Guideline 35: Use Decorators to Add Customization HierarchicallyYour Coworkers’ Design IssueThe Decorator Design Pattern ExplainedA Classic Implementation of the Decorator Design PatternA Second Decorator ExampleComparison Between Decorator, Adapter, and StrategyAnalyzing the Shortcomings of the Decorator Design PatternGuideline 36: Understand the Trade-off Between Runtime and Compile Time AbstractionA Value-Based Compile Time DecoratorA Value-Based Runtime Decorator

Guideline 37: Treat Singleton as an Implementation Pattern, Not a Design PatternThe Singleton Pattern ExplainedSingleton Does Not Manage or Reduce DependenciesGuideline 38: Design Singletons for Change and TestabilitySingletons Represent Global StateSingletons Impede Changeability and TestabilityInverting the Dependencies on a SingletonApplying the Strategy Design PatternMoving Toward Local Dependency Injection
Guideline 39: Continue to Learn About Design Patterns

Content preview from C++ Software Design

Chapter 5. The Strategy and Command Design Patterns

This chapter is devoted to two of the most commonly used design patterns: the Strategy design pattern and the Command design pattern. Most commonly used indeed: the C++ Standard Library itself uses both of them dozens of times, and it’s very likely that you have used them many times yourself. Both of these can be considered fundamental tools for every developer.

In “Guideline 19: Use Strategy to Isolate How Things Are Done”, I will introduce you to the Strategy design pattern. I will demonstrate why this is one of the most useful and most important design patterns and why you will find it useful in many situations.

In “Guideline 20: Favor Composition over Inheritance”, we will take a look at inheritance and why so many people complain about it. You will see that it’s not bad per se, but like everything else, it has its benefits as well as limitations. Most importantly, however, I will explain that many of the classic design patterns do not draw their power from inheritance but rather from composition.

In “Guideline 21: Use Command to Isolate What Things Are Done”, I will introduce you to the Command design pattern. I will show you how to use that design pattern productively, and also give you an idea of how Command and Strategy compare.

In “Guideline 22: Prefer Value Semantics over Reference Semantics”, we take a trip into the realm of reference semantics. However, we will find that this realm is not particularly friendly and ...