Home > Patterns and Practices > Visitor Pattern

Visitor Pattern

Visitor Pattern

Problem:

You have a stable class hierarchy and you got to add methods to all objects in the hierarchy. By the nature of the change you predict that more such methods might be required in the future too. For example, let’s take the insurance domain where we have modeled the HomePolicy, AutomobilePolicy and MedicalPolicy with the base class as Policy. Assume we need to export the Policy data as XML to external subsystems like Billing and Claims. Ours being a product we need to integrate with Claims, Billing, ReInsurance, Underwriting products from different vendors in the future. But then each of this could require the Xml in different formats. One solution is add these method on the Domain object like shown in the figure below:

But then this is not the best of the designs as our Domain Model is also entrusted with the responsibility of exporting the Policy data to subsystems. This also builds knowledge on what subsystems depend on the Policy data into the Domain object. Strictly speaking this violates the single responsibility principle.

 

Solution:

This would be a much better solution to the problem:

With this approach the Domain Model object is now not tied to logic of exporting the Xml to various sub system specific formats. The visitor pattern is matrix basically. The Policy classes of HomePolicy, AutoPolicy, MedicalPolicy are along one axis and the Exporter classes of BillingExporter, ClaimsExporter come on the other axis. Since the actual export operation depends on two method dispatches, this is also called as double dispatch. Also here we are hoisting out the export to xml aspects of the problem from the domain object. To an OO guys this is one of implementing AOP. Pure AOP guys might differ from this view though.

 

The GoF Class structure diagram is as shown below. The PolicyExporter interface is the Visitor interface in our case and the Export methods are semantically equivalent to the visit methods. The Billing and Claims Exporter classes are the concrete visitors. The Policy class is semantically equivalent to the Abstract Element class and the AutoPolicy, HomePolicy and MedicalPolicy classes correspond to the Concrete Visitors. The ExportXml method is semantically equivalent to the Accept Method. Though I could have named my classes methods to follow the accept, visit pattern followed by GoF, this seems much cleaner to me.

 

Advertisements
  1. No comments yet.
  1. November 19, 2010 at 11:00 pm
  2. November 19, 2010 at 11:09 pm

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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: