Exercise 3: Attaching a Second Bound View — Possible Solution
====================================================================

ATTACHING A SECOND VIEW, USING THIS CHAPTER'S OWN CLASSES UNCHANGED
------------------------------
    view_model = TodoViewModel()
    view_a = TodoBoundView()
    view_b = TodoBoundView()
    view_model.attach(view_a)
    view_model.attach(view_b)

No new code was needed - TodoViewModel._observers is already a list,
and attach() already just appends to it, exactly like Design Patterns'
own Stock.attach().

VERIFYING ONE CALL UPDATES BOTH VIEWS
------------------------------
    view_a.displayed_text: Todo list: Buy milk
    view_b.displayed_text: Todo list: Buy milk
    both updated from one call: True

Calling view_model.add_item('Buy milk') exactly once correctly updated
BOTH bound views, with identical resulting text - the same single call
that updated one view in this chapter's own original example now
fans out to as many attached views as are registered.

WHAT THE MVP EQUIVALENT WOULD HAVE REQUIRED
------------------------------
Using this chapter's own comparison table directly: in MVP, "who
updates the View?" is answered "the Presenter, explicitly, every
time." TodoPresenter.handle_add() calls self.view.show_items(...) on
exactly ONE specific view object it was given a reference to at
construction time. Supporting a second view in MVP would require
EDITING TodoPresenter itself - either giving it a list of views to
loop over and push to (mirroring what MVVM's _notify() already does
for free), or creating a second, separate Presenter instance wrapping
the same Model. Either way, MVP's own code has to change to add a
second view; MVVM's does not, because "notify everyone attached"
was already the mechanism, not a special case bolted on afterward.

WHY THIS WORKS AS AN ANSWER
------------------------------
The second view is attached using only this chapter's own existing
attach() method, the single-call/dual-update behavior is verified
directly, and the MVP comparison is grounded specifically in this
chapter's own comparison table row ("who updates the View?") rather
than a general claim that MVVM is "more flexible."