Behavioral Design Patterns

Design Patterns Quick Study Notes Home
.Net fundamentals Advanced c# topics ASP.net C# Interview Topics C# quick-study Entity Framework Core Notes Home
JS Fundamentals Advanced JS Topics Object Oriented in JS JS Interview Related JS Data Structures strange JS JS Frameworks Notes Home
Notes Home
Notes Home
JS interview prep c# interview prep SQL interview prep Notes Home
Chain of Responsibility

Chain of Responsibility

Very simple design pattern that lets components process a command or query in turn

Examples:

Simplest: simply make a reference chain, in theory, you could replace it with just an ordinary List, or perhaps, a LinkedList

Method Chain = singly-linked List essentially

More Sophisticated: Broker Chain. Implementation that also leverages Mediator and Observer patterns allows us to process queries on an event, letting each subscriber perform modifications of the originally passed object (single reference that goes through entire chain) before final values are returned to the client

Commands

Commands

Problem: no record of change / history on variable assignment

Solution: instead of working with objects directly by manipulating them through their APIs, we send them commands or instructions on how to do something.

Components can communicate with one another using special objects that encapsulate instructions, rather than specifying those same instructions as arguments to a method

Command Steps:

Command Steps example

Command Undo Operations:

Command Undo Operations example Command Undo Operations example 2

Composite Command:

Composite Command example
Interpreter

Interpreter Pattern

Uncommon pattern and removed from many universities

Interpreter Notes
Iterators

Iterator Pattern

Has been deliberately hidden in C# in favor of the simple IEnumerator/IEnumerable dupoply

ReactiveX also prides itself with implementing the iterator pattern

Iterator Notes Iterator Notes 2 Iterator Notes 3 Iterator Notes 4 Iterator Notes 5 Iterator Notes 6
Mediators

Mediator Pattern

situations when you don't necessarily want objects to be aware of each other's presence. (or maybe do but DON't want them to communicate through references...)

having an in-between componenet that everyone in the system has a reference to and can use to communicate with one another

Examples:

Chat room

Simplest: member list and a function that goes through the list and does what is intended to do

Sophisticated: use events to allow participants to subscribe (and unsub) to things happening in the system...this way messages from one component to another can be treated as events.

Mediator Events Mediator Behaviors Example Mediator Behaviors Example2
Mementos

Memento Pattern

when you care about being able to roll back the system to a particular state, if need be ...stores the state of the system and returns it as a dedicated, read-only object with no behavior of its own. "Token" used for feeding back into the system to restore its state

all about handing out tokens that can be used to restore the system to a prior state.

Memento Example
Null Objects

Null Object Pattern

You don't want a piece of functionality but it's built into the interface....you make a NULL object

NullObject Example NullObject Example 2
Observers

Observer Pattern

let's one component notify other components that something has happened

Thread safety is one concern when it comes to Observer, whether talking individual events or entire collections

    Observer Examples

  • JavaScript is a great place for the observable pattern because everything is event-driven
  • addEventListener. Adding an event listener to an HTML element has all the markings of the observer pattern
  • great library being used by many projects and that’s ReactiveX of which RxJS is its JavaScript counterpart.
  • 1) when binding data to the UI
  • 2) So popular that it's incorporated into c# via events
Observer Event basic Example Observer Event basic Example 2
Weak Event Pattern
Weak Event Pattern example
Property Observer
Property Observer example Property Observer example 2 Property Observer example 3 Property Observer example 4
Event Streams
Event Streams example Event Streams example 2 Event Streams example 3
Observable Collections
Observable Collections 1 Observable Collections 2
State

State Pattern

State Machines involve two collections: states and triggers. States model the possible states of the system and triggers transition us from one state to another.

    TWO ways to model states:

  • 1) States are actual classes with behaviors and these behaviors cause the transition from this state to another. State's members are the options in terms of where we can go from that state
  • 2) States and transitions are just enumerations. (have a special component called a state machine that performs the actual transitions)
State Example State Example Problems State Example Problems 2 State Example Problems 3

    More State Notes:

  • attempting to transition that is not configured will result in an exception
  • it is possible to explicity configure entry and exit actions for each state
  • transitions can be turned on and off through guard conditions. Can also be parameterized
  • States can be hierarchical; they can be substates of other states
Strategies

Strategy Pattern

allows you to define a skeleton of an algorithm and then use composition to supply the missing implementation details related to a particular strategy.

Dynamic Strategy

Dynamic strategy simply keeps a reference to the strategy currently (if you want to change to different strat...just change the reference)

Dynamic Strategy Example Dynamic Strategy Example 2
Static Strategy
Static Strategy Example
Templates

Template Pattern

very similar to strategy method

Strategy uses composition (whether dynamic or static) while Template uses inheritance

Template Example Game solution example 2
Vistors

Visitor Pattern

allows us to add some distinct behavior to every element in a heiarchy of objects

Intrusive Visitor - adding a method to every single object in the hierarchy. (breaks OCP)

Intrusive Visitor Example

Reflective - adding a separate Visitor that requires no changes to the objects. (uses the is/as whenever runtime dispatch as needed)

Reflective Visitor example 2

Dynamic - forces runtime dispatch via the DLR by casting hierarchy objects to dynamic.

Dynamic Visitor example

Classic - (double dispatch) every element of the hierarchy learns to Accept() a Visitor. We then subclass the Visitor to enhance the hiearchy's funtionality in all sorts of directions

Classic Visitor example Classic Visitor example

Acyclic Visitor

Cyclic Visitor (baed on funciton overloading

Acyclic Visitor based on type casting)