Design Patterns: The most common misconceptions - Klaus Iglberger - Meeting C++ 2023

Поділитися
Вставка
  • Опубліковано 15 лис 2024

КОМЕНТАРІ • 4

  • @SfrOschNOR
    @SfrOschNOR 9 місяців тому +4

    I always love to see some good conent about C++ Patterns which is unfortunately quite rare.

  • @wolpumba4099
    @wolpumba4099 9 місяців тому +4

    *Chapter titles*
    *I. Introduction to Design Patterns*
    - 00:00 Introduction and Background
    - 01:29 Understanding Design Patterns
    *II. The Role of Terminology in Design Patterns*
    - 02:53 The Importance of Correct Terminology
    *III. Exploring Common Misconceptions*
    - 04:37 Misconception 1: Builder Pattern
    - 12:01 Clarification on the GoF Builder Pattern
    - 16:08 Misconception 2: Factory Method
    *IV. In-Depth Design Pattern Analysis*
    - 27:01 Understanding Factory Functions and Factory Method Patterns
    - 29:12 Clarifying the Bridge (Pimpl Idiom) and Misconceptions
    - 39:17 Differentiating Bridge and Strategy Design Patterns
    *V. Broader Perspectives on Design Patterns*
    - 40:09 Design Patterns Beyond Object-Oriented Programming
    *VI. Conclusion*
    - 49:24 Concluding Remarks and Q&A Invitation
    *Summary*
    *Introduction and Background*
    - 00:00 Introduction to the talk on design patterns and common misconceptions.
    - 00:11 Introduction of the speaker, Klaus Iglberger, who is an author and expert on design patterns.
    - 00:35 The speaker clarifies that this talk will focus on terminology, specifically on commonly misused design pattern names.
    *Understanding Design Patterns*
    - 01:29 Explanation of what a design pattern is, emphasizing the importance of names for communication of intent.
    - 01:51 Design patterns aim to reduce dependencies through abstraction and concern separation.
    - 02:14 Clarification that abstractions in design patterns can include pointers, base classes, or templates.
    - 02:33 Mention that design patterns are discovered rather than invented due to their proven effectiveness over time.
    *The Importance of Correct Terminology*
    - 02:53 Discussion on the importance of terminology for design patterns.
    - 03:05 Reference to Kaa Lala's assertion on the benefits of using design patterns for understanding complex structures.
    - 03:29 Emphasis on mastering software complexity through the correct use of terminology.
    *Misconception 1: Builder Pattern*
    - 04:37 Initial confusion on LinkedIn about the favorite design pattern being the Builder pattern.
    - 04:52 The speaker's curiosity about which Builder pattern the respondents refer to.
    - 05:40 The majority reference Joshua Bloch's Builder pattern from his book "Effective Java."
    - 06:11 Comparison of Joshua Bloch's Builder pattern with the GoF (Gang of Four) Builder pattern from the classic design patterns book.
    - 06:53 Implementation of Joshua Bloch's Builder pattern in C++ for a widget class with many constructor parameters.
    - 08:24 Discussion on the differences between the two Builder patterns.
    *Clarification on the GoF Builder Pattern*
    - 12:01 Explanation of the GoF Builder pattern, focusing on construction and representation separation.
    - 12:14 Overview of the GoF Builder pattern structure and its intention.
    - 12:46 Importance of architectural boundaries and managing dependencies in true design patterns.
    *Misconception 2: Factory Method*
    - 16:08 Discussion of the common misuse of the term "Factory method" to describe any function that creates an object.
    - 16:14 Example of creating shapes from JSON to illustrate a factory function.
    - 16:27 Argument that a function creating an object is not a design pattern, but an implementation detail.
    - 16:55 Elaboration on the necessity of an architectural boundary for a design pattern, using a shapes creation function as an example.
    - 17:38 Introduction of a function pointer as an illustration of the Factory Method design pattern.
    - 18:17 Contrast between a simple factory function and the Factory Method design pattern's role in dependency inversion and design.
    - 19:23 Explanation of the actual Factory Method design pattern through an abstract example using function pointers and base class hierarchies.
    - 26:50 Summary stating that a "Factory method" is not the same as a "Factory function," and in C++, there are no methods, only functions.
    *Understanding Factory Functions and Factory Method Patterns*
    - 27:01 The speaker invites listeners to verify by checking the C++ standard draft online.
    - 27:34 Discusses the improper use of the term "method" in C++ when referring to functions.
    - 27:53 Explains the correct use of "Factory function" and "Factory method" in the context of design patterns.
    - 28:06 Points out that Wikipedia's definition of "Factory" in object-oriented programming may confuse readers between general factory concept and the specific Factory Method pattern.
    - 28:39 Emphasizes the difference between general factory functions that create objects and the Factory Method design pattern that involves customizable creation processes.
    *Clarifying the Bridge (Pimpl Idiom) and Misconceptions*
    - 29:12 Introduces the topic of the bridge pattern, also known as the pimpl (pointer to implementation) idiom.
    - 29:47 Uses the example of an electric car to illustrate a scenario where the technology changes frequently.
    - 30:04 Describes the potential issues with including a fast-changing "battery" class within the "electric car" class.
    - 30:58 Proposes using a pointer to decouple the dependency on the battery class.
    - 31:22 Discusses the incorrect notion that passing a "battery" to the constructor makes it a bridge pattern.
    - 32:26 Demonstrates the misconception that any use of a pointer to an object is an implementation of the bridge pattern.
    - 33:01 Refers to the original description of the bridge pattern from the design patterns book and the importance of hiding implementation details.
    - 34:00 Corrects the example of bridge pattern usage by showing that it should not involve passing an implementation detail through the constructor.
    - 34:17 Highlights that naming a data member "pimpl" or "impl" does not automatically make it a bridge pattern.
    - 36:07 Illustrates the proper implementation of the bridge pattern where the "electric car" class creates its own "battery" internally, hiding the implementation details.
    - 37:13 Compares the bridge and strategy design patterns, emphasizing internal customization (bridge) versus external customization points (strategy).
    *Differentiating Bridge and Strategy Design Patterns*
    - 39:17 Explains that the bridge pattern is about internal customization without dependency injection.
    - 39:41 Clarifies that the strategy pattern refers to external customization, typically achieved through dependency injection.
    - 40:01 Expands the discussion to consider the broader application of design patterns beyond object-oriented programming.
    *Design Patterns Beyond Object-Oriented Programming*
    - 40:09 Addresses a critique that mistakenly associates design patterns solely with object-oriented programming.
    - 40:33 Argues against the notion that modern C++ features make most object-oriented principles unnecessary.
    - 41:35 References Andrei Alexandrescu's book on template-based design patterns as an early example that design patterns are not restricted to object-oriented programming.
    - 42:08 Examines various C++ standard library features, like `unique_ptr` and `vector`, as examples of strategy design patterns without inheritance.
    - 42:54 Shows how algorithms like `std::accumulate` and `std::generate` use templates for customization, which can be considered factory methods or strategies.
    - 44:03 Discusses different approaches to dependency injection in C++, including template parameters, function pointers, base classes, and `std::function`.
    - 44:58 Concludes that design patterns serve to manage software complexity and are not exclusive to object-oriented programming.
    *Concluding Remarks and Q&A Invitation*
    - 49:24 Concludes the talk by emphasizing the importance of terminology in design patterns and their role in managing software complexity.
    - 49:32 Opens the floor for questions and encourages the audience to take a break and get some lunch.
    Disclaimer: I used gpt4-1106 to summarize the video transcript. This
    method may make mistakes in recognizing words and it can't distinguish
    between speakers.

  • @CppZiedAlaya
    @CppZiedAlaya 9 місяців тому +1

    Great talk as usual, thanks (again) Kalaus 👍

  • @sadranezam3367
    @sadranezam3367 9 місяців тому

    eagle burger lol