C++ Design Patterns — Static Init Fiasco & Pitfalls

Every large C++ codebase — game engines, trading systems, operating systems — is held together not just by algorithms but by structure. That structure comes from design patterns. When a new engineer joins the Unreal Engine team, they don't need to reverse-engineer why the rendering subsystem is built the way it is. The patterns make the intent obvious. That's the superpower patterns give you: code that communicates its own design decisions.

The problem patterns solve is accidental complexity — the kind that grows when you solve the same structural problem a dozen different ways across the same codebase. Without patterns, you end up with object creation scattered everywhere, tight coupling between subsystems that should never talk directly, and notification chains that are impossible to trace. Patterns give you a vocabulary and a discipline: a shared contract between you and every developer who reads your code in the future.

By the end of this article, you'll be able to implement the Gang of Four's most important patterns in modern C++ (C++17/20), understand the performance tradeoffs each one carries, recognise when a pattern is being abused, and walk into a senior engineering interview and explain not just how a pattern works but why it exists and when you'd reject it.

Creational Patterns: The Factory Method

In large-scale C++ applications, hardcoding object creation using the new keyword creates tight coupling. If you decide to change the underlying class implementation, you have to hunt down every instance of new across your project. The Factory Method pattern provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects that will be created.

In modern C++, we often pair this with std::unique_ptr to ensure exception safety and automatic memory management, adhering to RAII principles.

But here's the thing: a factory switch-based on an enum is a code smell in itself. It violates the Open/Closed principle because every time you add a new product, you must modify the factory switch. Better alternatives include a registry of factory functions keyed by string (or type index) that can be extended without modifying the factory class. In HFT systems, that table is often populated at startup via static initialisation of plugin modules.

Structural Patterns: The Strategy Pattern & Modern CRTP

While traditional Strategy patterns rely on virtual function calls (runtime polymorphism), C++ allows for 'Static Polymorphism' via the Curiously Recurring Template Pattern (CRTP). This avoids the overhead of a VTable lookup, making it a favorite in high-frequency trading (HFT) and game physics engines.

By passing the derived class as a template parameter to the base class, the compiler can resolve function calls at compile-time, allowing for aggressive inlining.

But static polymorphism locks your strategy at compile time. If you need to swap strategies based on a runtime config file or user input, CRTP won't work — you'll need the classic Strategy pattern with virtual functions. The decision tree is simple: if the strategy is known when you write the code (e.g., different validators for different input types that never change), use CRTP. If the strategy is chosen during runtime (e.g., a compression algorithm selected from a UI dropdown), use virtual dispatch. Mix both in a hybrid: use a small virtual interface over a CRTP implementation to get inlining where possible and runtime selection where needed.

Creational Patterns: Thread-Safe Singleton (Meyers Singleton)

The Singleton pattern ensures a class has only one instance and provides a global point of access to it. In C++, the most robust implementation is the 'Meyers Singleton' (named after Scott Meyers), which uses a function-local static variable. Since C++11, the initialization of function-local static variables is guaranteed to be thread-safe by the standard — no mutexes or double-checked locking needed.

But Singleton is often overused. It introduces global state, making code tightly coupled and hard to test. Before applying it, ask: does this truly need to be a single instance? Often a dependency injection framework or a factory that creates one instance (and passes it around) is cleaner. For truly unique resources (hardware driver, logging system, global configuration), Singleton is acceptable, but always pair it with a unit-testing seam: allow replacing the instance via a setter in testing builds.

Be aware of the static initialization order fiasco when two Singletons depend on each other (see production incident above). Meyers Singleton is lazy and thread-safe, but if one Singleton's constructor calls another Singleton, you can still get into trouble. Break cyclical dependencies by using explicit initialization steps in main().

Behavioral Patterns: The Observer Pattern (with Weak Pointers)

The Observer pattern defines a one-to-many dependency between objects: when one object changes state, all its dependents are notified automatically. In C++, implementing a thread-safe Observer requires careful resource management.

The classic pitfall: storing raw pointers to observers and not notifying them after they're destroyed — causes dangling pointer crashes. The fix: store std::weak_ptr<Observer> and lock before calling. Also protect the subscription list with a std::mutex because notification can happen from any thread.

Another consideration: the order of notification is undefined — never rely on it. And the notifier should not hold locks while calling observers (to avoid deadlocks). A common pattern is to copy the observer list under a lock, then iterate the copy outside the lock.

Creational Patterns: The Builder (Fluent Interface)

When a class requires many optional or interdependent parameters, constructor overloading becomes unmanageable. The Builder pattern separates the construction of a complex object from its representation, allowing the same construction process to create different representations.

In C++, a fluent Builder returns *this from setter methods, enabling method chaining. This is especially useful for configuration objects, database connections, or HTTP request builders. C++20 introduced designated initializers which can partially replace Builder for simple cases, but for validation and interdependent parameters, Builder is still the right tool.

One production gotcha: Builders often perform validation in their build() method. If validation fails, they can return an std::optional<T> or throw. Never leave the object in a partially constructed state. Another trap: Builders that own raw pointers instead of smart pointers — always store the final object in a std::unique_ptr or return by value if the object is movable.

Frequently Asked Questions