Log In
Or create an account -> 
Imperial Library
  • Home
  • About
  • News
  • Upload
  • Forum
  • Help
  • Login/SignUp

Index
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
  • ← Prev
  • Back
  • Next →
  • ← Prev
  • Back
  • Next →

Chief Librarian: Las Zenow <zenow@riseup.net>
Fork the source code from gitlab
.

This is a mirror of the Tor onion service:
http://kx5thpx2olielkihfyo4jgjqfb7zx7wxr3sd4xzt26ochei4m6f7tayd.onion