C++ܛ���O(sh��)Ӌ(j��)

Preface 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