Chapter 07 — Behavioral Design Patterns

How behavior and communication are distributed among objects. The lecture covers Iterator and Observer in detail and names the rest of the family for recognition.

07chapter

—lists

—total items

Behavioral Design Patterns

13 lists

Definition & Mnemonic I.O.

Behavioral patterns are responsible for the efficient and safe distribution of behaviors among a program's objects
Iterate — Iterator gives a standard way to walk a collection
Observe — Observer gives a standard way to watch an object for changes

The Behavioral Family 11

Covered in detail: Iterator and Observer. The rest are named so you recognize them as behavioral.

Chain of Responsibility
Command
Interpreter
Iterator — covered
Mediator
Memento
Observer — covered
State
Strategy
Template Method
Visitor

Iterator — Intent 2 keys

Access the elements of a collection sequentially, one after another in a defined order
Without knowing the representation — array, linked list or tree, no client breaks

Iterator — Participants 5

Client — talks to the Aggregate and Iterator interfaces only
Aggregate — declares createIterator()
ConcreteAggregate — returns a concrete iterator over its own data
Iterator — declares hasNext() and next()
ConcreteIterator — holds the position and accesses the concrete aggregate

Iterator — Build Order (I.C.C.A.) 5 steps

I — design the Iterator interface
C — design a concrete Iterator for each collection structure
Implement its methods in terms of that data structure
C — create the Collection interface with the iterator-creating method
A — implement the Aggregate interface in each collection class

Iterator — Benefits 3

A consistent way for clients to iterate over any collection
Abstracts the internals — collections can change without changing clients
Extensible — many iterators for different traversals (standard, reverse, filtered)

Iterator — The Key Detail 1

The position lives on the iterator, not the collection — so several iterators can walk one collection independently

Observer — Intent 3 keys

One-to-many — one Subject, many Observers
Dependency — observers care about the subject's state; the subject does not care what they do with it
Automatically — nobody polls; the subject pushes the notification on state change

Observer — Participants 4

Subject — holds the observer list; attach(), detach(), notifyAll()
ConcreteSubject — holds the state and notifies on change
Observer — declares the abstract update()
ConcreteObserver — implements update() and registers itself

Observer — Build Order (S.I.O.I.R.) 5 steps

S — design the Subject interface with attach, detach and notify
I — inherit from it in classes holding information of interest
O — design the Observer interface with an abstract update()
I — implement update() in every observer
R — register observers at run time; the subject iterates and calls update on change

Observer — Benefits 2

Flexibility to add new services without touching the Subject
Services are compartmentalized, so maintaining and modifying them is easier

Iterator vs Observer compare

	Iterator	Observer
Solves	Walking a collection without knowing how it stores elements	Many objects reacting the moment one object's state changes
Relationship	One client to one traversal at a time	One Subject to many Observers
Cue phrase	"access the elements sequentially without exposing the representation"	"one-to-many dependency, notified automatically"
Where they meet	The Subject iterates its observer list inside notifyAllObservers()

The Three Categories, Side by Side 3

Category	Concerned with	This course's patterns
Creational	How objects get created	Abstract Factory, Factory Method, Singleton, Builder, Prototype
Structural	How classes and objects are composed into larger structures	Adapter, Composite, Facade
Behavioral	How behavior and communication are distributed	Iterator, Observer