Design Patterns discussion

["Chris Finlayson" <cfinlayson AT vls-inc.com>]

Wayne
-


The examples you provided are good motivators of when to use the Visitor
pattern - it's much more clear to me now.  I still say the example in the
Design Patterns book - while useful in showing how to implement Visitor
pattern doesn't truly demonstrate its necessity.  Your examples (particulary
"a warehouse that wants an inventory of equipment (lists  of quantities and
prices of Equipment on hand organized by  type/sub-class") I think
demonstrate its necessity more clearly without much extra code.

My specific comments below
--Chris.

> -----Original Message-----
> From: Wayne Cannon 
> [mailto:nospam AT sonic.net]
> Sent: Saturday, March 20, 2004 9:47 AM
> To: 
> cfinlayson AT vls-inc.com
> Cc: 
> gang-of-4-patterns AT cs.uiuc.edu
> Subject: Re: [gang-of-4-patterns] Benefits of the visitor pattern in
> Go4's example - I don't understand
>
>
> Your example doesn't say how EquipmentPricingPolicy is used?
EquipmentPricingPolicy oPolicy(oEquipment);
Currency oNetPrice = oPolicy->GetNetPrice();
etc.


> For example, a Visitor pattern could be used to walk through
> all of the individual pieces of Equipment in a customer order
> (in Equipment' Composite structure) to generate a price for
> the order, using EquipmentPricingPolicy to compute the
> appropriate price for each piece of Equipment.
It could be, but I was just arguing that the simplistiic example didn't
provide much motivation of using the Visitor pattern.

> Since you
> defined the EquipmentPricingPolicy separate from the
> Equipment class, itself, you are already well down the road
> to being able to take advantage of the Visitor pattern.
But why bother with the double-dispatch structure, is my fundamental
question, with this simple example?
>
> The Visitor pattern becomes an advantage when you want the
> independence and freedom to add various new operations (like
> pricing a multi-piece order) without "polluting" the purpose
> of the original objects.

You can still do this without "polluting" the purpose of the original
objects.  In the case of getting information about these classes, i.e. the
price, we still need an accessor method - e.g. GetNetPrice() in the
Equipment classes regardless of whether we use the Visitor or not.


>
> Instead, you can create multiple Visitor patterns.  The
> Equipment class can be focused solely on "being Equipment",
> and not contain code for every way Equipment can be used.
> You can then have separate Visitor classes for things like
> (1) a warehouse that wants an inventory of equipment (lists
> of quantities and prices of Equipment on hand organized by
> type/sub-class),

Yes - this makes sense. This example, and the others you list below, are a
much better example of demonstrating the benefits of the Visitor pattern.

> (2) a catalog generation that generates a
> list, description, and price of all possible equipment
> types/sub-classes, (3) a layout program that provides an
> equipment layout for a particular installation using a
> Visitor pattern to get size and shape/outline information
> from the base Equipment class, (4) a shipping manifest with
> Equipment type and weight for the Equipment in a particular
> shipment, (5) a manufacturing plan that needs to determine
> how many sub-assemblies are required for a desired number of
> Equipment pieces, (6) a costing program that computes the
> cost contribution of all of the subassemblies plus the added
> cost of the top level assembly, and (7) an Equipment editor
> that allows you to search for a particular type or piece of
> equipment based on some set of characteristics and display a
> dialog box for modifying it or creating a new variant of it.
> There may be different collections/structures of Equipment
> (e.g., in-stock inventory, catalog of all possible Equipment,
> an order, a multi-order shipment, etc.).  Each Visitor walks
> the appropriate structure.

> An addition benefit of the Visitor class is that the
> Equipment class may be defined by one part of an organization
> (the designers or manufacturers of that equipment) while the
> Visitor patterns may be defined by other parts of the
> organization (marketing, shipping, accounting, application
> engineering, etc.).  Separating the Equipment base class from
> the Visitor classes fits well with the organizational
> boundaries, helping to minimize code sharing and
> communications across organizations.
Yes - this makes sense.

>
> abstract class Equipment
> {
>       String getName();
>       CatalogDescription getCatalogDescription();
>       LengthWidthHeight getSize();
>       Weight getWeight();
>       MonetaryValue getCostOfThisAssembly();
>       LayoutOutline getTopViewLayoutOutline();
>       LayoutOutline getSideViewLayoutOutline();
>       LayoutOutline getEndViewLayoutOutline();
>       EquipmentCollection getSubAssemblies();
> }
>
> Regards,
> Wayne
> --
> [Replace "nospam" with "wcannon" for legitimate reply address.]
>
>
> 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.
> >
> >
>
>
>