C++ Software Design Klaus Iglberger

Kup polskie wydanie:

Dostępność produktu

Produkt nie został jeszcze oceniony pod kątem ułatwień dostępu lub nie podano żadnych informacji o ułatwieniach dostępu lub są one niewystarczające. Prawdopodobnie Wydawca/Dostawca jeszcze nie umożliwił dokonania walidacji produktu lub nie przekazał odpowiednich informacji na temat jego dostępności.

Spis treści książki

• 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
  • OReilly 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
    • Dont 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 Patterns 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

pokaż cały spis treści

ukryj recenzje