book

Object-Oriented Software Design in C++

Name: Object-Oriented Software Design in C++
Author: Ron Mak
ISBN: 9781633439504

by Ron Mak

June 2024

Beginner

520 pages

12h 20m

English

Manning Publications

Audiobook available

Read now

Unlock full access

Object-Oriented Software Design in C++
Copyright
contents
front matter
prefaceExperience is the best teacheracknowledgmentsabout this bookWho should read this book?How this book is organized: A roadmapAbout the codeliveBook discussion forumabout the authorabout the cover illustration
Part 1. Introduction
1 The path to well-designed software
1.1 What is software design?1.2 What you will learn from this book1.3 The benefits of good software design1.4 A few design examples1.4.1 Leaking changes1.4.2 Code that’s too complex1.4.3 Inflexible code1.4.4 Surprise!1.4.5 Common architecture problems1.5 Make sure we’re going to build the right application; then, build it right1.6 Good design doesn’t come easily1.7 Change and complexity are the enemies of good design1.8 Design with object-oriented programming conceptsSummary
2 Iterate to achieve good design
2.1 Good application design requires an iterative process2.2 Don’t let changes leak out2.3 Iterate to achieve good design2.3.1 Iteration 1: Initial cohesive classes2.3.2 Iteration 2: Encapsulation, delegation, and loose coupling2.3.3 Iteration 3: More kinds of books and their attributes2.3.4 Iteration 4: A better design after backtrackingSummary
Part 2. Design the right application
3 Get requirements to build the right application
3.1 The overture to application design3.2 Functional requirements: What must the application do?3.3 Nonfunctional requirements: Constraints on the application3.4 What are good requirements?3.5 How to get requirements3.5.1 A short requirements case study3.5.2 Stated and implied requirements3.6 Unified Modeling Language diagrams for creating and documenting design3.7 Use cases provide context for the requirements3.7.1 UML use case diagram3.7.2 Use case description3.8 The functional specification and software validation3.9 Where do classes come from?3.9.1 Textual analysis: Nouns can become classes3.9.2 Textual analysis: Verbs can become member functionsSummary
4 Good class design to build the application right
4.1 When do we do application design?4.2 Two important goals for good class design4.2.1 Cohesion and the Single Responsibility Principle4.2.2 Loose coupling and the Principle of Least Knowledge4.3 UML class diagrams to document class design4.4 Class relationships determine runtime interactions4.4.1 Dependency: The most basic relationship4.4.2 Aggregation and composition: Objects that contain other objects4.4.3 Generalization: Superclasses and their subclasses4.4.4 Abstract classes and interfaces: What subclasses must implement4.5 UML state diagram: How an object changes state4.6 UML sequence diagram: How objects interact [optional]4.7 The design specification and software verificationSummary

Part 3. Design the application right
5 Hide class implementations
5.1 The Principle of Least Knowledge and hidden implementations5.2 Public getter and setter functions access hidden implementation selectively5.3 Class Date: An example of implementation hiding5.3.1 Iteration 1: Date arithmetic with loops5.3.2 Iteration 2: Julian day numbers simplify date arithmetic5.3.3 Iteration 3: A hybrid approach with lazy evaluation5.4 Public setter functions carefully modify hidden implementation5.5 Beware of dangerous setter functions5.6 Rules from the Law of Demeter5.7 But is the implementation really hidden?5.8 The Open-Closed Principle supports code stabilitySummary
6 Don’t surprise your users
6.1 No surprises and the Principle of Least Astonishment6.1.1 Off-by-one errors6.1.2 Misnamed functions can mislead their callers6.2 Poor performance is an unwelcome surprise6.2.1 Bad design can cause unexpected performance problems6.2.2 The vexatious performance of C++ vectors6.3 Programming by Contract helps to eliminate surprises [optional]6.3.1 Programming a circular buffer by contract6.3.2 Precondition: What must be true before calling a function6.3.3 Postcondition: What must be true after returning from a function6.3.4 Class invariant: What must remain true of object statesSummary
7 Design subclasses right
7.1 When to use function overriding or overloading7.1.1 Override superclass member functions to get subclass behavior7.1.2 Overload functions that have similar or equivalent behaviors7.2 The Liskov Substitution Principle and proper subclasses7.3 Choosing the is-a and has-a relationships7.4 Use a factory function with the Code to the Interface Principle7.5 Programming by Contract with subclasses [optional]Summary
Part 4. Design patterns solve application architecture problems
The benefits of design patternsExplaining the design patternsThe sports examples
8 The Template Method and Strategy Design Patterns
8.1 The Template Method Design Pattern defines the steps of an algorithm8.1.1 Desired design features8.1.2 Before using the Template Method Design Pattern8.1.3 After using the Template Method Design Pattern8.1.4 Template Method’s generic model8.2 The Strategy Design Pattern encapsulates algorithms8.2.1 Desired design features8.2.2 Before using the Strategy Design Pattern8.2.3 After using the Strategy Design Pattern8.2.4 Strategy’s generic model8.3 Choose between Template Method and StrategySummary
9 The Factory Method and Abstract Factory Design Patterns
9.1 The Factory Method Design Pattern lets subclasses create objects9.1.1 Desired design features9.1.2 Before using the Factory Method Design Pattern9.1.3 After using the Factory Method Design Pattern9.1.4 Factory Method’s generic model9.2 The Abstract Factory Design Pattern creates families of objects9.2.1 Before using the Abstract Factory Design Pattern9.2.2 After using the Abstract Factory Design Pattern9.2.3 Abstract Factory’s generic modelSummary
10 The Adapter and Façade Design Patterns
10.1 The Adapter Design Pattern integrates code10.1.1 Desired design features10.1.2 Before using the Adapter Design Pattern10.1.3 After using the Adapter Design Pattern10.1.4 Adapter’s generic model10.1.5 An alternative Adapter Design Pattern model10.2 The Façade Design Pattern hides a subsystem of interfaces10.2.1 Desired design features10.2.2 Before using the Façade Design Pattern10.2.3 After using the Façade Design Pattern10.2.4 Façade’s generic modelSummary
11 The Iterator and Visitor Design Patterns
11.1 The Iterator Design Pattern encapsulates iterating over different sequential collections11.1.1 Desired design features11.1.2 Before using the Iterator Design Pattern11.1.3 After using the Iterator Design Pattern11.1.4 Iterator’s generic model11.2 The Visitor Design Pattern encapsulates different algorithms that operate on a data collection11.2.1 Desired design features11.2.2 Before using the Visitor Design Pattern11.3 After using the Visitor Design Pattern11.3.1 Visitor’s generic modelSummary
12 The Observer Design Pattern
12.1 The Observer Design Pattern represents the publisher–subscriber model12.1.1 Desired design features12.1.2 Before using the Observer Design Pattern12.1.3 After using the Observer Design Pattern12.1.4 The Observer’s generic modelSummary
13 The State Design Pattern
13.1 The State Design Pattern models state transitions13.1.1 Desired design features13.1.2 Before using the State Design Pattern13.1.3 After using the State Design Pattern13.1.4 State’s generic modelSummary
14 The Singleton, Composite, and Decorator Design Patterns
14.1 The Singleton Design Pattern ensures a class has only one object14.1.1 Desired design features14.1.2 Before using the Singleton Design Pattern14.1.3 After using the Singleton Design Pattern14.1.4 Singleton’s generic model14.2 The Composite Design Pattern treats individual and composite objects uniformly14.2.1 Desired design features14.2.2 Before using the Composite Design Pattern14.2.3 After using the Composite Design Pattern14.2.4 Composite’s generic model14.3 The Decorator Design Pattern dynamically adds object responsibilities14.3.1 Desired design features14.3.2 Before using the Decorator Design Pattern14.3.3 After using the Decorator Design Pattern14.3.4 Decorator’s generic modelSummary
Part 5. Additional Design Techniques
15 Designing solutions with recursion and backtracking
15.1 Recursion compared to the for loop15.2 Finding the largest value by recursion15.3 Reversing a vector by recursion15.4 Solve the Towers of Hanoi puzzle by recursion15.5 Recursive algorithms for a binary search tree15.5.1 Inserting into a BST with recursion15.5.2 Printing a BST with recursion15.5.3 Removing all the nodes of a BST with recursion15.6 Quicksort an array with recursion15.6.1 Quicksort in action15.6.2 Partitioning an array into subarrays15.6.3 Quicksort implementation15.7 The Fibonacci sequence and a recursion disaster15.8 Dynamic backtracking increases the power of recursion15.9 Solving the eight queens puzzle with recursion and backtracking15.10 Solving Sudoku puzzles with recursion and backtrackingSummary
16 Designing multithreaded programs
16.1 How do things happen simultaneously?16.2 A mutex enforces mutual exclusion16.2.1 Protect the integrity of a shared resource16.2.2 The classic reader–writer problem16.3 Condition variables synchronize threads16.3.1 How condition variables synchronize threads16.3.2 The classic producer–consumer problem16.4 A final note on multithreadingSummary
index

404

Not Found

Either this content does not exist or you do not have access to it. Try searching for something new.

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Object-Oriented Software Design in C++

by Ron Mak

404

Not Found