book

C++ Software Design

Name: C++ Software Design
Author: Klaus Iglberger
ISBN: 9781098113162

by Klaus Iglberger

September 2022

Intermediate to advanced

438 pages

10h 45m

English

O'Reilly Media, Inc.

Read now

Unlock full access

Includes

Sandbox

Preface
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
1. The Art of Software Design
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
2. The Art of Building Abstractions
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
3. The Purpose of Design Patterns
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
4. The Visitor Design Pattern
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
5. The Strategy and Command Design Patterns
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
6. The Adapter, Observer, and CRTP Design Patterns
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
7. The Bridge, Prototype, and External Polymorphism Design Patterns
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
8. The Type Erasure 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
9. The Decorator Design Pattern
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

10. The Singleton Pattern
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
11. The Last Guideline
Guideline 39: Continue to Learn About Design Patterns
Index
About the Author

Content preview from C++ Software Design

Chapter 3. The Purpose of Design Patterns

Visitor, Strategy, Decorator. These are all names of design patterns that we’ll deal with in the upcoming chapters. However, before taking a detailed look at each of these design patterns, I should give you an idea about the general purpose of a design pattern. Thus in this chapter, we will first take a look at the fundamental properties of design patterns, why you would want to know about them and use them.

In “Guideline 1: Understand the Importance of Software Design”, I already used the term design pattern and explained on which level of software development you use them. However, I have not yet explained in detail what a design pattern is. That will be the topic of “Guideline 11: Understand the Purpose of Design Patterns”: you will understand that a design pattern has a name that expresses an intent, introduces an abstraction that helps to decouple software entities, and has been proven over the years.

In “Guideline 12: Beware of Design Pattern Misconceptions”, I will focus on several misconceptions about design patterns and explain what a design pattern is not. I will try to convince you that design patterns are not about implementation details and do not represent language-specific solutions to common problems. I will also do my best to show you that they are not limited to object-oriented programming nor to dynamic polymorphism.

In “Guideline 13: Design Patterns Are Everywhere”, I will demonstrate that it’s hard to avoid design ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781098113155Errata Page

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

C++ Software Design

by Klaus Iglberger

Chapter 3. The Purpose of Design Patterns

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.