The Visitor Pattern – Part 2

In Part 1 of this series we learned about the benefits of the Visitor Pattern and saw a basic approach according to the GoF description.

As clean and elegant the visitor pattern might look in the first place, it nonetheless has its disadvantages. Say, we want to add a new shape TShapeTriangle. We have to do it inside the same unit the other shapes are declared. As the shapes reference the visitor and the visitor references the shapes we have to put all shape classes together with the visitor into the same unit. Although this might work in some smaller scenarios, it definitely doesn’t in most of the real ones. Probably this is one of the reasons why the Visitor Pattern is not as famous as it should be.

Can we find a solution? Yes, we can!

Lets examine why there is such a close coupling between all the shapes and the visitor: The shapes use the visitor’s method corresponding to their own class and the visitor has to know about all the shapes it has to handle. How can we break this up?

The answer are interfaces! Instead of declaring a visitor capable of handling every defined shape, we declare an interface for each shape that only handles that specific shape.

Author: Uwe Raabe

Addicted to Pascal/Delphi since the late 70's