On Design Patterns in C++
fluentcpp.com
fluentcpp.com
GoF book is well obsolete, since then OO has faded, JS & Python are the the most common tools, even Java is unrecognizable with Lambdas and functional features everywhere. Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful and immutability is now a valid design goal. The GoF needs an update.
I'd argue that they still are relevant. The only thing that's seen more impressive growth than memory volume is the relative cost of a cache miss. So the great irony is, one of the most efficient ways to sabotage your CPU power is to make use of all that RAM.
Has the cost of cache misses truly increased? (Also: relative to what?)
Today's CPUs have far larger caches than in the past (and not to mention a lot faster too), so the number of cache misses and the time cost of each cache miss for the same program on a modern CPU should be much lower—right?
And I'd agree with that statement. I have been doing some heavy profiling lately and it's fun to see how good are modern processors at executing even non-optimal code if it's cache friendly. However, the moment it needs to hit L3 cache or further, the pipeline stalls and performance goes down the drain.
On the cache side, it's true that caches are bigger. But then we run into that old saw about software people's greatest achievement being to negate to efforts of hardware people. Caches get twice as big, and programmers decide the best thing to do with all that extra space is using 64-bit numbers as a matter of habit, or perhaps even switching to programming languages that don't have 32-bit numbers. Or by switching to dynamic languages that cram the cache full of pointers and object headers. Things like that.
Which isn't to say that all of these practices are objectively bad - spending computing resources on human productivity is typically a very good trade-off. Just that there's no such thing as a free lunch. Memory usage still has a performance cost, and, in stark contrast to how things worked a quarter century ago, it now kicks in long before the system starts experiencing actual memory pressure.
1: See, for example: https://assets.bitbashing.io/images/mem_gap.png
Partially this is due to configuration variability. A lot of laptops are still configured in single channel mode. Even high-end laptops tend to be dual channel setups, even if the CPU itself supports more. I'm inclined to say that high-end CPUs configured for 4 (or more) channels are rare enough that you probably shouldn't expect to be able to enjoy one unless you're developing in-house software where you can know exactly what kind of hardware you'll be running on.
And partially it's due to contention. All the memory channels in the world won't help you when memory access starts to pile up on the same bank. Which is, in practice, going to be something that will happen all the time if you're not taking steps to keep it form happening, because that's the kind of unhelpful jerk that stochastic processes are.
In practice if you have more memory buses they are more likely to be useful to help more processes or threads make simultaneous progress than to speed up one process. For a single thread to make good use of more memory buses usually requires using memory pre-fetch intrinsics and memory sequestration, and even then it is hard to keep more than two or three usefully engaged for that thread.
So, your point stands.
> Meanwhile vast amounts of memory and CPU power mean flyweights and object pools aren't so useful and immutability is now a valid design goal.
I don't agree, they are still widely used in most languages, but are often hidden behind abstractions so that developers don't need to know about them.
I totally agree that patterns are important and useful, I just think that the way they're presented and over-emphasized is net-harmful, and that by changing that we can make the situation better.
Well, but it does, doesn't it?
I mean, the first step to solve a problem is to identify it. Clearly, the problem with design patterns is that clueless developers have no idea what they are talking about, thus they mount incomprehensible complains that make no sense if you'd understood the basics.
Developing software is a complex endeavor that is much more than declare variables and nest control statements. There is way more to developing software than what is covered by a "intro to language X" or "learn framework Y" blog post.
If a programming language gives you brick and mortar, you start to talk about retaining walls and windows and stairs. If a programming language gives you gears and screws and bearings and springs, you start to talk about pumps and differentials and dampers.
So what's hard to understand in needing design patterns to talk about components and solutions to common problems?
We know how to write good widgets now, but designing your program such that it scales well and doesn't rot is still difficult (e.g. lots of mutable state is fast but is much harder to scale when you introduce concurrency)
It's really the same issue, isn't it? specially if you follow a component-based design. The difference is only in the level where the discussion is set.
Having said that, personally I've seen a tight correlation between those who criticize about design patterns and those who criticizd software architecture.
In fact, the higher the abstraction, the higher the criticism. It seems the furthest the subject is from the critic's comprehension and experience, the more their criticize.
If you're looking for a newer book on design patterns, I've heard Head First Design Patterns (2004) suggested as much more approachable. The cover image is a bit goofy and screams mid-2000s. I've only seen excerpts, but GoF if I remember correctly is very dry and doesn't explain some things very well. Head First Design Patterns looks to be written for Java, but I don't remember having trouble understanding and implementing them in other languages.
Head First Design Patterns: Building Extensible and Maintainable Object-Oriented Software 2nd Edition will be released on December 29. I guess this is the newer edition? It shares 2 of the authors.
I've heard that statement before and it really never made any sense to begin with.
Design patterns describe higher-level concepts. Just because a higher level concept made its way into a standard library that doesn't male it go away, nor does it eliminate the need to reason and have higher level discussions involving it.
Take for example C#. Does it make sense to talk about event loops in C#? Or observers? Or callbacks? Because those are all design patterns, aren't they? Great, you don't need to add a lot of boilerplate code to get to use one, but you're still using the concept and reasoning about the system in terms of these patterns and their features and properties, right?
Just because I can buy a ready-made roof instead of having to cut down trees or buy the wood somewhere, that doesn't mean that a roof is no longer a roof.
Were the language up to the job, the pattern would have been captured in a named library component, and no longer be a Pattern at all. Use of a well-designed and -tested library component is always better than re-coding the pattern again at each new use.
A classical example is the hash table. In C, and similarly limited languages, you cannot write a useful hash table library. Instead, custom hash tables are re-coded over and over again in thousands of individual programs and libraries wherever they are needed.
In other, similarly limited languages, the pattern is pulled into the core language, as a "dictionary" or "map" type, eliminating most need to re-code it, at the expense of flexibility in its design.
In more expressive languages like C++ and Rust, hash table libraries arise, and the most commonly useful forms appear in the standard library.
We have continually added to C++ and its library as we have identified patterns. New patterns arise in composing existing features and library components, so adding to them creates new opportunties for patterns to arise. As each new pattern is identified, it may be captured. Sometimes this demands new core language support for abstraction, as is seen in new Concepts and Coroutines core features. So, we naturally expect to see new library components that use the new features in commonly seen ways.
The expected addition of pattern matching to core C++, similarly to what appears in Rust and certain other languages, represents a lapse: a failure to discover and specify core language features to add that would enable implementing usefully general pattern matching as a family of library components. Conflict over, e.g. simplicity vs generality, in design of the core feature is unavoidable, where, were it implementable as a library, different choices could be captured as different library components.
Anytime we lapse and fail to discover core language primitives needed to implement a high-level construct, we should remember and see each use of it as a rebuke, and motivation to invent core features that would have made it redundant.
OO Design patterns are usually about implementing functional concepts into rigid OOP languages such as C++ or Java (though both languages have gotten better).
With first class functions, there is no need for factories or strategies, or commands or a lot of stuff that imply single method classes.
With pattern matching, there is no need for chains or responsibility and so on and so forth...
We don't often see data-structure patterns nowadays just because such patterns were recognized early as in need of core language features to capture them into libraries. Hash tables were a tough nut, so the core features that are needed to capture them in libraries, or even direct core-language implementations, didn't make it into some of the languages that are still in common use.
The set of patterns that can be captured into a library is a moving target for a language that is still evolving rapidly, and for the landscape of new and upcoming languages; but a fixed target for a mature language like C. In C, X can, Y can't, and that will probably always be true of C.
As time goes on, the set of patterns that can be captured into libraries of new and evolving languages grows, and with it our expectations of new languages. A language, new or old, that fails to capture what other languages are seen to do (for reasons) is rightly seen as less powerful.
There is a place for less powerful languages, for use in limited domains, that are therefore quicker to learn and maybe safer to use, for less experienced or more distracted users. But we should always be clear about why the language is being made or kept less powerful, and what is lost by it.
When starting a new project with open-ended goals, we don't know what challenges the project will face and whether a deliberately limited language will be enough for the job. By the time we learn, it is generally far too late to change horses. Thus, aging OS kernels and databases we use are often still coded in C largely because that was all that was practically available when they started out.
Go is a recent deliberately-limited language that, because it was chosen to implement projects with open-ended goals, is getting painful extensions, and getting harder to learn. Rust was deliberately limited to reduce the burden of implementing its toolchain and to make it easier to pick up, but is rapidly expanding (according to plan) to satisfy the growing needs of its increasingly sophisticated user base.
It's like claiming an algorithm is a design pattern. No. In the context of GoF as talked in the linked article, a design pattern isn't anything you see hand-coded in multiple programs.
No they are not, not in the context of the GoF design patterns which is what the thread is about, nothing else.
An expanded awareness of unavoidably repeated constructs remains useful.
yet it's irrelevant to the topic at hand. You can't just make up your own definition to suit your argument when the related article talks about something completely different, it's dishonest.
You can pass function pointers around all you want, it's just fucking difficult to get right without practice and the syntax is abhorrent.
I don't know if I would recommend these books today but they are undeniable classics.
Is having parameters at all "The Parameter Pattern"? Should we call passing a boolean flag "The Flag Pattern"?
To me, "Design Pattern" implies at least some higher order structure than that (and which is not natively abstractable over in the language in question).
Regarding the strategy pattern, when does it start becoming the pattern and when is it just "passing a function as a parameter"?
sortList(list, [](const item& i) {return i.name();});
struct MySorter
{
bool operator ()(const item&) {...}
};
sortList(list, MySorter{});
class MySorter : public ISorter
{
public:
virtual bool execute(const item&) override {...}
};
sortList(list, MySorter{});So yes, there are trivial things which you can argue the toss on, but in the last month I've used HTTP libraries that don't allow you to supply a strategy for retry logic and machine learning libraries that don't allow a strategy for early stopping.
Yes
> Should we call passing a boolean flag "The Flag Pattern"?
The fact that we call it a flag, in itself a metaphor, shows that this is exactly what is happening already. We just omit the "pattern" as it is not necessary for understanding.
Pattern just means "something that occurs repeatingly". Some things do so obviously, others a bit less obviously.
My experience teaching comp. sci. is that when faced with problems that call for design patterns, ~40% of 20/22 y.o. students are able to come up with the "classical" design pattern implementations on their own in a couple hours without prior exposure to them. For the rest, well, we have the books.
I think this is even mentioned in the GoF book. The point of naming these patterns is not that they're amazingly innovative. The point of "Patterns" is that when we give them a name we can (a) discuss them easier with a common language, and (b), we can recognise when we use them again so to remember the pitfalls of last time.
Other languages, like e.g. Rust (because of lack of HKT), cannot express monads like Haskell can.
But yeah, you can definitely call it a design pattern if that’s what the culture around the language is like. But it would be like Java folks calling interfaces with default implementations for something goofy like “Interface with stateless implementations pattern”, and even they don’t go that far.
But in Haskell, a lot of the time you don't use a monad because you want a monad. You use a monad to do something else - to log in a pure way, for example. That use of a monad to solve a particular problem is a pattern.
I'd even argue that it's using the pattern to compensate for a weakness of the language. (Or, if you prefer, to help with things that are difficult within the language design and philosophy.)
You mean like a bit field?
Did you realized that with only two words you can convey amultitude of information regarding it's use and implementation and properties?
Two words.
Perhaps there is more to design patterns than mindlessly complaining about stuff you don't fully understand.
I think we've done a poor job as an industry of beating new developers over the head with "know the tradeoffs!" Design patterns are taught without teaching their tradeoffs, and so new developers think that it's best practice to apply every possible design pattern as eagerly as possible.
I agree that naming patterns is useful, but IME they've been a net negative on the code bases I've worked on, since the way they're taught encourages using them mindlessly without considering their costs.
In the same way, any sufficiently complicated C++ program contains an ad hoc, informally specified, bug ridden implementation of half of the Gang of Four design patterns. They would be better off just using the patterns, instead of trying to roll their own half-baked solutions to the same problems.
If you've got one of those problems, use the standard, tested solution. If you don't have one of those problems, don't shoehorn in a solution that doesn't fit.
It's not that hard to grasp (except for junior devs who have recently read a pattern book...)
Design patterns can reduce a lot of unnecessary cognitive overhead. For example, a builder pattern that takes a config a returns an evaluation pipeline is really simple and eliminates a lot of runtime if..else conditions.
Are you really trying to argue that a collection of terminology aimed at describing high level concepts, or standard solutions to commonly repeating problems and requirements, is a code smell?
What other good engineering practices are also code smells?
/s
Design Patterns are tools in a box, aiming to create scalable solutions, but the way a solution is implemented is up to the implementer. Design patterns just try to establish the language.
Looking back at when the book was published, we had PowerPlant, CSet++, SOM, COM, CORBA, Turbo Vision, OWL, MFC, VCL, Motif++.
Definitely representative.
I like C++, and yes there is more to C++ than those OOP frameworks, yet lets not pretend that what gave birth to Java like enterprise coding came from C++ development practices during the decade that preceded it.