Design Patterns Part 3

Topics covered
Popular Clips
Episode Highlights
Observer Pattern
The Observer Pattern is a fundamental concept in software design, often seen in the form of a publisher-subscriber model. Joe Zack explains that while the pattern is straightforward, real-world applications often require tweaks, as textbook examples rarely fit perfectly 1. He highlights the importance of understanding the pattern's limitations, such as abstraction layer hopping, which can lead to unintended system relationships 2. Michael Outlaw adds that Microsoft's reactive extensions provide interfaces like IObservable and IObserver to facilitate this pattern 3.
The Observer pattern does not cover unsubscribe. It's strictly pub sub.
--- Michael Outlaw
This pattern is commonly used in scenarios like chat servers, where multiple users need to be notified of changes in real-time.
  Â
Chain of Responsibilities
The Chain of Responsibilities pattern is a design approach that allows requests to be passed along a chain of handlers. Michael Outlaw describes exception handling as a prime example, where exceptions are caught and potentially re-thrown up the call stack until handled 4. Joe Zack notes that this pattern can be confusing due to its lack of strong use cases, but it is often seen in hierarchical decision-making processes, like procurement systems 5.
This is an example where it's not 100% the pattern as described in the book, because there's no inheritance.
--- Joe Zack
The concept of a "chain of chains" or "tree of responsibility" further illustrates its complexity and adaptability 6.
  Â
Iterator Pattern
The Iterator Pattern is essential for traversing collections without exposing their underlying structures. Michael Outlaw explains that this pattern decouples traversal logic from the container, allowing users to access elements sequentially without knowing the data's representation 7. Joe Zack emphasizes the pattern's utility in scenarios like file reading, where the data's storage format is irrelevant to the user 8.
The iterator is responsible for like sequentially, and that's the keyword there, sequentially, keeping track of its state.
--- Joe Zack
However, using iterators can lead to issues, such as conflicts when modifying collections during iteration 9.
Related Episodes
Design Patterns Part 1
Answers 383 questionsCommand, Repository and Mediator Design Patterns
Answers 383 questions

Software Design Anti-patterns
Answers 383 questionsClean Code - How to Write Amazing Functions
Answers 383 questionsDesign Patterns Part 4 - Adapter, Facade, and Memento
Answers 383 questionsDesigning Data-Intensive Applications – Scalability
Answers 383 questions

Clean Code - How to Write Classes the Right Way
Answers 383 questionsHow to be a Programmer
Answers 383 questionsThe DevOps Handbook – Enable Daily Learning
Answers 383 questionsBehavioral Patterns Pt 1
Answers 383 questions95. Data Structures – Arrays and Array-ish
Answers 383 questions

Strategic Design and Domain Events
Answers 383 questionsHow to be an Intermediate Programmer
Answers 383 questions

Why Domain Driven Design
Answers 383 questionsWhat is Supple Design?
Answers 383 questions
