Design Patterns discussion

["David Rosenstrauch" <darose AT dti.net>]

In other words, Visitor is much more applicable when you have a large
complex tree many levels deep - not just a simple Composite.  The Visitor
"walks" the tree, "visiting" each node in it.  The double dispatch is
needed so that the visitor can find out what exact type of object it is
visiting (without needing to do something kludgey like instanceof).
If this doesn't make things clearer and you have more questions, feel free
to email back with them.
HTH,

DR


oleg shteynbuk said:
> Example that you describe is from the “Sample Code” of the Visitor and
> in the first paragraph of this section you can find: “The Equipment
> classes are so simple that using Visitor isn't really necessary, but
> they make it easy to see what's involved in implementing the pattern”.
> They probably anticipated your email :) Motivation section has other
> example that shows that advantage of the Visitor.
>
> Oleg
>
>
>
> Chris Finlayson wrote:
>
>>Hi:
>>
>>I don't understand the advantage a Visitor pattern provides in the
>>context of the Go4 example - I was wondering if someone could help
>>clarify this for me.
>>
>>If one has a composite - such as the Equipment composite that the Go4
>>discuss and one wants to compute the cost of equipment, I don't get why
>>the PricingVisitor is advantageous.  Why bother with the
>>double-dispatch mechanism over this well-defined Composite interface?
>>
>>For example, instead of the PricingVisitor, we could have something
>>like:
>>
>>class EquipmentPricingPolicy
>>{
>>
>>public:
>>      EquipmentPricingPolicy(Equipment* oEquipment)
>>      {
>>              m_oEquipment = oEquipment;
>>      }
>>      Currency GetNetPrice()
>>      {
>>              return m_oEquipment->NetPrice();
>>      }
>>
>>      Currency GetDiscountPrice()
>>      {
>>              return m_oEquipment->DiscountPrice();
>>      }
>>
>>      Currency GetSavings()
>>      {
>>              return GetNetPrice() - GetDiscountPrice();
>>      }
>>
>>      //etc. etc.
>>
>>private:
>>      Equipment* m_oEquipment
>>}
>>
>>So, when m_oEquipment->NetPrice() is called, it gets the net price of
>>the equipment - since Equipment is implemented following the Composite
>>design pattern.  This seems more straightforward.
>>
>>
>>What I CAN understand is how a visitor is applicable in working with
>>many disparate classes of distinct interfaces.  I.e., if one is piecing
>>together disparate modules of some legacy code, each having their own
>>definition of an Equipment and how to return its net price.  I do not,
>>however, understand how it is advantageous for a set of classes
>>adhering to a well-defined interface, as the Equipment class' adhere
>>to.
>>
>>
>>--Chris.
>>
>>
>>_______________________________________________
>>gang-of-4-patterns mailing list
>>gang-of-4-patterns AT cs.uiuc.edu
>>http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns
>>
>>
>>
>
> _______________________________________________
> gang-of-4-patterns mailing list
> gang-of-4-patterns AT cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/gang-of-4-patterns