I hate the term “Design Patterns”. It implies there are universally applicable solutions to some common code scenarios. Just codifying existing practice into some rules and blindly following them is a comfortable path, but not the optimal one. It turns out it’s not as easy as following recipes. Each situation and best associated solution is unique.
However there is value in having uniform code structure throughout a project. So this topic is not to be discarded just yet, rather it needs more careful examination.
In terms of inspectable properties of objects, what have we learned from years of OO influence from other languages and frameworks? How can we leverage these borrowed techniques in a value-oriented context? Does C++ benefit from special considerations?
I think it’s time to revisit our old friend, the Observer pattern - from “theory” to practice. I’m not going to offer The Solution, rather we’re going to examine tradeoffs for several possible implementations, in various usage scenarios from a real project.
ALL TALK SESSIONS CAN BE ACCESSED FROM THE MAIN LOBBY:
https://cppcon.digital-medium.co.uk/
