1. “The Trouble with Observer” and “Visitor Revisited”
Presentation by Matt Deckard

2. The Trouble with Trib- I mean Observer

3. The Trouble with Observer
Runtime redundancy
every subject object duplicated in observer
lots of pointers
tradeoff for reuse
Static redundancy
inheritence in all subject and object subclasses
parallel hierarchy
everything multiplied by two
mechanical overhead
conceptual overhead

4. The Trouble with Observer
What to do?
cut down to one hierarchy
but retain benefits of redundancy
hmm...
What if...
instead of storing info, compute it on the fly
tradeoff between space and time
ok, as long as we don't demand info "very often"
in UI example:
subject changes
user input
UI redraw

5. The Trouble with Observer
reduce observer object hierarchy to constant number
reduce number of links too
compute them on the fly too?
demand for info involves traversal of Observer hierarchy
so why don't we do our computation here?
traverse *Subject* structure to update
Subjects have flag to determine whether they need updating

6. The Trouble with Observer
B-b-but...
where do you keep the Subject's presentation code?
depends on both the kind of Subject and the kind of presentation
It's time to visit our friend...
Visitor
define Visitor class called Presenter
Visit operations for each Subject class
also implements traversal methods

7. Visitor Revisited But what about... Adding new Subject classes
don't want to add new Visit operations to every Presenter
use a "default" visit for abstract Subject
can also put all common behavior here, have reimplemented Visits call it
subclass Presenter to implement specific visit operations for new Subjects
use "default" visit, but dynamically cast to new subtype
must use overloading for this to work

8. Visitor Revisited But why not just...
cast the new Presenter subclass in the new Subject's accept?
much harder to add these things back into base Presenter
have to change Subject hierarchy instead of Presenter hierarchy

9. Visitor Revisited Drawbacks
lumped all functionality from ConcreteObservers into one Visitor
could be fixed by delegating to Strategy objects
what if Observers need to save state that's not computable on the fly?
save data in separate associative data structure, keyed by Subject
looks good on paper, not sure about practice