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

The Trouble with Trib- I mean Observer

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

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

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

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

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

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

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