Visitor Family of Design Patterns

Driver: The visitor family allows separation of concerns and allows functionality (basically one or more methods) to be added to a hierarchy of classes without modifying anything in the hierarchy.

For instance: in the visitor pattern, the visitable classes would just define a single method (accept) in the simplest case and within that a ploymorphic call would be made to the passed in Visitor instance’s visit() method.

OCP principal: (the Open Closed Principle): The visitor family allows changing the behavior of existing classes (for instance, in the case of the Visitor Pattern, these classes are termed as Visitable) without updating the existing codebase.

The main patterns of interest in this family are:

  • Visitor
  • Decorator

The Visitor Pattern:

There is a dual dispatch happening wherein the first dispatch is to invoke the correct accept method in case there are more than one.

The second dispatch is to invoke the correct visit() method on the Visitor instance.

One of the main benefits of the visitor pattern is that it is extremely fast as it involves only two polymorphic dispatches.

The Decorator Pattern:

This one is different from visitor although they are members of the same family of patterns – the Visitor family. It is primarily different  ’cause it does not require the interface of the Visitable to be updated with the addition of the accept() method. There are no dual dispatches.

This pattern is also called the toolkit pattern since new tools (new behavior) can be acquired at run time => the application therefore can be termed to be using new tools.

The SRP principle (Single Responsibility Principle) underlines the separation of concerns in a good design. This implies, in a decorator context, that a class (such as one representing the entity: CAR)  should not burden itself with a characteristic (such as the alloy wheels) that is not intrinsic to its behavior. In the case of the preceding example of a CAR, the decorator can implement the interface of the CAR and delegate all calls to the CAR instance but "decorate" the one for getPrice() by taking into account the presence of alloy wheels and adding that to the base price and thereafter delegating to the CAR instance.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

     

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">