So far, I have discussed in my previous posts the Singleton Pattern, and its pros and cons. One question is still open: What alternatives for the Singleton Pattern are available? Today, I write about the Monostate Pattern and Dependency Injection.
The finance industry is a big user of C++. But as everyone knows, C++ programmers take on a substantial burden of complexity relative to other languages. Why would they do that? In a word: for performance. With C++, you retain full semantic expressiveness without sacrificing any speed. But that complexity can be tough.
I introduced in my last post “The Singleton“, the classical Singleton and the so-called Meyers Singleton. The Singleton Pattern is highly controversial. Let me, therefore, discuss in this post the pros and cons of the Singleton.
The most controversial Design Pattern from the book “Design Patterns: Elements of Reusable Object-Oriented Software” is the Singleton Pattern. Let me introduce it before I discuss its pros and cons.
In the last installment of this blog, I introduced the Factory Method: Creational Patterns: Factory Method 1. My implementation had two serious issues: slicing and ownership semantics. Today, I fix these issues.
Training and mentoring aim one goal: to improve your skills in a well-defined way. Although both aim for the same goal, they use very different ways. One may fit your needs, but not the other.
The classic book “Design Patterns: Elements of Reusable Object-Oriented Software” has 23 patterns. They are ordered by intent: creational, structural, and behavioral patterns. Today, I focus on the creational pattern Factory Method.
An anti-pattern is a proven way to shoot yourself into your foot. The term anti-pattern was coined by Andrew Koenig, and it is pretty entertaining to read about them.
Patterns don’t live in isolation, they are in relation to each other. A relation can mean they are in contrast to each other, connected, build a sequence of patterns, build a repository of patter, or even a pattern language. Let’s dive deeper into these relations.
The classics “Design Patterns: Elements of Reusable Object-Oriented Software”, and “Pattern-Oriented Software Architecture, Volume 1” use similar steps to present their pattern. Today, I will present this structure of a pattern.