Exercises — Design Patterns — Behavioral - Observer, Strategy, Command, Iterator, State, Template Method, Chain of Responsibility,

Pattern: Observer.

• The Temperature object is the Subject: it keeps a list of listeners and calls notify() on change.
• Each display/logger is an Observer: it implements a common update(data) method. Why not the others? The key phrase is "one thing changes → many things react automatically, added/removed at runtime". That fan-out is Observer's exact signature. See Publish-Subscribe & Event-Driven Architecture for the same idea at network scale.

Pattern: Strategy.

• The checkout is the Context; each payment algorithm is a Strategy implementing one pay(amount) interface.
• The client picks which strategy object to hand in; the context never branches on the method name.

Pattern: Command. Each action becomes an object with execute() and undo(). A history list stacks them, so undo() pops and reverses. This is exactly Undo-Redo Systems.

class Bell:
    def __init__(self):
        self._observers = []            # subject owns the list
    def subscribe(self, o):  self._observers.append(o)
    def ring(self, msg):
        for o in self._observers:       # decoupled fan-out
            o.update(msg)
 
class Student:
    def __init__(self, name): self.name = name
    def update(self, msg):    print(f"Ding for {self.name}: {msg}")
 
b = Bell(); b.subscribe(Student("Ana"))
b.ring("lunch")

Output: Ding for Ana: lunch Note ring returns nothing — Observer is push, the subject does not collect answers.

class Calculator:
    def __init__(self, strategy): self.strategy = strategy
    def run(self, a, b): return self.strategy(a, b)   # delegate, no if/else
 
print(Calculator(lambda a, b: a + b).run(4, 6))   # 10
print(Calculator(lambda a, b: a * b).run(4, 6))   # 24

Results: 10 then 24. In Python a plain function is a strategy — no class hierarchy needed.

class AddNumber:
    def __init__(self, doc, n): self.doc, self.n = doc, n
    def execute(self): self.doc.append(self.n)
    def undo(self):    self.doc.pop()
 
doc, history = [], []
def run(cmd): cmd.execute(); history.append(cmd)
def undo():   history.pop().undo()
 
for n in (10, 20, 30): run(AddNumber(doc, n))
undo()

After the three runs doc == [10, 20, 30]; one undo() pops the last, giving doc == [10, 20], sum 30.

1. Who chooses the object. Strategy: the client injects it. State: the object often creates its successor.
2. Knowledge of siblings. Strategy objects are independent and ignorant of each other. State objects know the next state and trigger the switch.
3. Frequency of change. A Strategy is usually set once and stays. A State changes repeatedly during the context's life (Draft → Moderation → Published). Structure is identical; intent distinguishes them (see Polymorphism — both lean on it, differently).

It is not Strategy — the algorithms are hard-coded inside an if/elif, so adding a "shuffle" mode means editing Sorter. That violates the Open/Closed Principle (open for extension, closed for modification). True Strategy:

class Sorter:
    def __init__(self, strategy): self.strategy = strategy
    def sort(self, data): return self.strategy(data)
 
asc  = Sorter(sorted)
desc = Sorter(lambda d: sorted(d, reverse=True))
print(asc.sort([3, 1, 2]))    # [1, 2, 3]
print(desc.sort([3, 1, 2]))   # [3, 2, 1]

Now a new algorithm is a new object, no edit to Sorter.

• L1 (max=2): 5 > 2 → cannot handle → passes to next.
• L2 (max=4): 5 > 4 → cannot handle → passes to next.
• Manager (max=10): 5 <= 10 → handles it. The chain stops at the first handler able to cope. Each handler only knows its successor, never the whole chain — that is the decoupling Chain of Responsibility buys.

Combine State (the mode decides behavior and the next mode) with Observer (target-change fan-out).

• Thermostat is the Context and the Subject.
• Eco/Comfort/Away are State objects returning a target temperature.
• Display/Logger are Observers.

class Eco:     target = 18
class Comfort: target = 23
 
class Thermostat:
    def __init__(self):
        self.state = Eco(); self._obs = []
    def subscribe(self, o): self._obs.append(o)
    def set_mode(self, state):
        self.state = state
        for o in self._obs:            # Observer fan-out
            o.update(self.state.target)

Setting the mode changes State; the resulting target-change triggers Observer notification. Each pattern owns one axis of change.

fresh = []
for cmd in history:            # Iterator: for-loop over the command stack
    AddNumber(fresh, cmd.n).execute()

Iterating history (Iterator) and calling each stored execute() (Command) rebuilds the sequence: fresh == [10, 20, 30], sum 60. Because commands are first-class objects, they can be stored, iterated, and replayed — that is what makes macros and redo possible.

class Draft:
    def publish(self, ctx): ctx.state = Moderation()
    def archive(self, ctx): print("cannot archive a draft")   # rejected
class Moderation:
    def publish(self, ctx): ctx.state = Published()
    def archive(self, ctx): print("cannot archive under moderation")
class Published:
    def publish(self, ctx): print("already live")             # safe no-op
    def archive(self, ctx): ctx.state = Archived()
class Archived:
    def publish(self, ctx): print("archived is final")
    def archive(self, ctx): print("already archived")
 
class Doc:
    def __init__(self): self.state = Draft()
    def publish(self): self.state.publish(self)
    def archive(self): self.state.archive(self)

Trace from Draft:

1. d.publish() → Draft.publish → state becomes Moderation.
2. d.publish() → Moderation.publish → state becomes Published.
3. d.archive() → Published.archive → state becomes Archived. Final state: Archived. Every illegal transition is handled by the state that owns it, so no scattered if checks exist — adding a new status is adding a class.

Pattern: Visitor.

• Each node accepts a Visitor via accept(visitor), which calls back visitor.visitParagraph(self) etc. New operations = new Visitor classes; the node classes stay untouched (respects Open/Closed for operations).
• Trade-off: Visitor makes adding new operations cheap but adding a new node type expensive — every existing visitor must gain a visitNewNode method. So Visitor is right precisely when the node hierarchy is stable and operations grow. If it were the reverse (nodes change often), Visitor would be the wrong tool.

Symptom "one change, many reactors, runtime add/remove" ::: Observer Symptom "one task, interchangeable algorithms chosen by client" ::: Strategy Symptom "actions must be stored, queued, undone" ::: Command Symptom "behavior changes as internal status changes, states know successors" ::: State Symptom "request tried by handlers until one copes" ::: Chain of Responsibility Symptom "add operations to a fixed, locked class hierarchy" ::: Visitor Structure of Strategy and State is identical; what distinguishes them ::: intent (who chooses / do objects know their successor)