Book Image

Hands-On Design Patterns with C++ (Second Edition) - Second Edition

By : Fedor G. Pikus
5 (1)
Book Image

Hands-On Design Patterns with C++ (Second Edition) - Second Edition

5 (1)
By: Fedor G. Pikus

Overview of this book

C++ is a general-purpose programming language designed for efficiency, performance, and flexibility. Design patterns are commonly accepted solutions to well-recognized design problems. In essence, they are a library of reusable components, only for software architecture, and not for a concrete implementation. This book helps you focus on the design patterns that naturally adapt to your needs, and on the patterns that uniquely benefit from the features of C++. Armed with the knowledge of these patterns, you’ll spend less time searching for solutions to common problems and tackle challenges with the solutions developed from experience. You’ll also explore that design patterns are a concise and efficient way to communicate, as patterns are a familiar and recognizable solution to a specific problem and can convey a considerable amount of information with a single line of code. By the end of this book, you’ll have a deep understanding of how to use design patterns to write maintainable, robust, and reusable software.
Table of Contents (26 chapters)
1
Part 1: Getting Started with C++ Features and Concepts
5
Part 2: Common C++ Idioms
10
Part 3: C++ Design Patterns
18
Part 4: Advanced C++ Design Patterns

Visiting complex objects

In the last section, we saw how the Visitor pattern allows us to add new operations to the existing hierarchy. In one of the examples, we visited a complex object that contained pointers to other objects. The visitor iterated over these pointers, in a limited way. We are now going to consider the general problem of visiting objects that are composed of other objects, or objects that contain other objects and build up to the demonstration of a working serialization/deserialization solution at the end.

Visiting composite objects

The general idea of visiting complex objects is quite straightforward - when visiting the object itself, we generally do not know all the details of how to handle each component or contained object. But there is something else that does - the visitor for that object type is written specifically to handle that class and nothing else. This observation suggests that the correct way to handle the component objects is to simply visit...