vistor pattern — my code ^ literature

My GS xml serializer is very close —
* my formatter objects {the visitors?} have overLOADED format(TradeGC) or format(SITradeGC).
* TradeGC and SITradeGC {the visitables?} both have a this.myFormatter.format(this) method. This IS the   entry point.

* double dispatch
* passing “this” around
* formatting logic belongs in the visitor classes.
* overLOADed methods resolved at compile time, based on arg declared type 

—- given a Family of visitable data classes + a family of visitor classes, you want to implement a full matrix. In every combination of visitor/visitable class, there’s special logic. Will the logic live in visit() or accept()? Will see.

Dynamic dispatch can be used only once (not sure why). The other dispatch is static dispatch — A key feature of visitor pattern. By convention, visit() is name of the static dispatch and accept() is the name of the dynamic dispatch ie virtual function.

We always have a visitor instance and a visitable instance waiting in the wings before the show starts. The typical show starts with theVisitable.accept(theVisitor). Entire show runs on a thread, with one method calling another in a call stack. Remember accept is resolved by dynamic dispatch. Within accept(), we see theVisitor.visit(this). This is a funny way of saying theVisitor.visit(theVisitable). This call is resolved by static dispatch.

The specific logic is implemented in a specific visit() method. If there are 3 x 2 combinations, then that many visit() methods.

Note the family of visitable data classes must implement public virtual method Accept(IVisitor)
Note the family of visitor classes should share a common base like IVisitor. IVisitor should declare abstract overload methods like visit(VisitableA) visit(VisitableB) etc.

—-http://www.objectmentor.com/resources/articles/visitor.pdf is a simple example using modems. —
* visit(visitable) — defined in the visitor object
** visit(visitable) method is overLOADED — visit(Type1_inFamily), visit(Type2_InFamily), visit(Type3_InFamily). resolved at compile time based on arg declared type. Static dispatch
** myVisitor.visit(this) called by a method in visitable — theVisitableObject.accept(theVisitor)

( This is the confusing part of visitor pattern)
* visitable.accept(visitor) — Ignore until you are clear about the above. Defined inside each visitable object, but usually very thin and adds nothing but confusion.
** I believe accpet(visitor) is usulaly a virtual method resolved at run time by dynamic dispatch

* double-dispatch — passing “this” around
** “double” refers to accept(..) and visit(..). One static one dynamic dispatch
* family — of visitable data-objects
* family — of visitors
* ==> matrix of 2 type hierarchies (see article)

I feel there’s tight coupling between visitable CLASSES and the visitor CLASSES

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s