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

Acyclic Visitor

The Visitor pattern, as we have seen it so far, does what we wanted it to do. It separates the implementation of the algorithm from the object that is the data for the algorithm, and it allows us to select the correct implementation based on two run-time factors - the specific object type and the concrete operation we want to perform, both of which are selected from their corresponding class hierarchies. There is, however, a fly in the ointment - we wanted to reduce complexity and simplified the code maintenance, and we did, but now we have to maintain two parallel class hierarchies, the visitable objects and the visitors, and the dependencies between the two are non-trivial. The worst part of these dependencies is that they form a cycle - the Visitor object depends on the types of the visitable objects (there is an overload of the visit() methods for every visitable type), and the base visitable type depends on the base visitor type. The first half of this dependency...