Design Patterns - The Most Common Misconceptions (1 of N) - Klaus Iglberger - NDC TechTown. 2023

This talk was recorded at NDC Techtown in Kongsberg, Norway. #ndctechtown #ndcconferences #cplusplus #developer #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences...
ndctechtown.com/
Subscribe to our KZbin channel and learn every day:
/‪@NDC‬
Design patterns are everywhere, as they are the key to managing dependencies between software entities.
But despite their fundamental importance, there are some common misconceptions about them, in particular about several of the most often used design patterns:
Factory functions are frequently mistaken for the Factory Method design pattern
The Builder design pattern is often associated with the implementation of constructors
The Bridge and Strategy design patterns are regularly mixed-up
The modern form of the Visitor design pattern, std::variant, is often considered a replacement of virtual functions
(Bonus) The Decorator design pattern is sometimes mistaken as the Chain of Responsibility design pattern
In this talk I'll shed some light on these misconceptions and explain why they obstruct the proper communication about software design and architecture. Additionally, I’ll address the biggest misconception of all: design patterns are a tool for object-oriented programming.

[@zdabka]

Good talk, especially to refresh some of the basic ideas about design patterns. Thanks!

[@johanngerell]

Love it!

[@wolpumba4099]

Okay, here is a summary of the provided transcript in a self-contained bullet list format: *Design Patterns and Terminology: A Discussion on Misconceptions and Clarifications* * *0:00:14** Introduction:* The speaker, Klaus Iglberger, introduces the topic of design patterns and their misconceptions, emphasizing the importance of terminology. * *0:00:28** Design Pattern Definition:* A design pattern has a name that carries meaning, aims at reducing dependencies, provides abstraction, and is usually discovered rather than invented. * *0:00:54** Terminology Matters:* Proper terminology is crucial for effective communication about code. Consistent application of design patterns helps manage software complexity. * *0:03:58** Builder Pattern Misconception:* Many people mistakenly refer to the "Joshua Bloch Builder" (often used for simplifying constructors with many parameters) as a design pattern. It's a useful technique but not a true design pattern as it doesn't involve an architectural boundary or dependency inversion. It is actually a fluent interface. * *0:09:01** Gang of Four Builder Pattern:* The actual Builder pattern, as described by the Gang of Four, separates the construction of a complex object from its representation, allowing different representations to be created using the same construction process. * *0:11:28** Terminology Clarification:* When using the term "Builder," be specific about whether you're referring to the Gang of Four Builder or the Joshua Bloch Builder. * *0:12:13** Factory Method Misconception:* A creation function is not automatically a factory method. The factory method is a design pattern that involves an architectural boundary and dependency inversion. * *0:14:37** Factory Method Explanation:* The factory method defines an interface for creating an object but lets subclasses decide which class to instantiate. It allows for customization of object creation without depending on concrete details. * *0:19:58** Terminology Clarification:* Distinguish between a general "factory function" (anything that creates something) and the "factory method" design pattern (a customizable factory function). * *0:21:54** Bridge Pattern Misconception:* The Bridge pattern is often confused with dependency injection. The Bridge pattern is about hiding implementation details, not about injecting dependencies. * *0:25:14** Bridge Pattern Explanation:* The Bridge pattern decouples an abstraction from its implementation so that the two can vary independently. It involves an internal customization mechanism, not dependency injection. * *0:30:28** Dependency Structure:* The Bridge pattern has the abstraction and implementation on the same architectural level, while the Strategy pattern (which often involves dependency injection) has them on different levels. * *0:31:24** Terminology Clarification:* Use "Bridge" for internal customization and "Strategy" for external customization via dependency injection. * *0:31:54** Design Patterns Beyond Object-Oriented Programming:* Design patterns are not limited to object-oriented programming. They are essential building blocks for software development and can be implemented using various techniques, including templates. * *0:33:56** Strategy Pattern in the Standard Library:* The C++ standard library uses the Strategy pattern extensively (e.g., `std::unique_ptr`'s deleter, `std::vector`'s allocator). * *0:38:18** Conclusion:* Terminology surrounding design patterns is crucial for managing software complexity. Design patterns are everywhere and are essential for good software design. * *0:39:48** Q&A:* Discussion about whether a specific example is a Factory method or a Command pattern, with the conclusion that the most important point is to recognize the dependency management aspect. * *0:41:27** Further Discussion:* The speaker mentions his book on pattern-oriented architecture and a previous talk about design patterns in modern C++, highlighting the use of template parameters for customization. He emphasizes the importance of discussing design and the big picture, not just language details. I used gemini-1.5-pro-exp-0827 on rocketrecap dot com to summarize the transcript. Cost (if I didn't use the free tier): $0.06 Input tokens: 47869 Output tokens: 870

[@theintjengineer]

I really Klaus' way of instructing. Very engaging.

[@coding_with_thomas]

Thanks for uploading tris Talk 😊