Chapter 35. Visitor

© Jennifer M. Kohnke

"'Tis some visitor," I muttered, "tapping at my chamber door;

Only this and nothing more."

Edgar Allen Poe, The Raven

You need to add a new method to a hierarchy of classes, but the act of adding it will be painful or damaging to the design. This is a common problem. For example, suppose that you have a hierarchy of Modem objects. The base class has the generic methods common to all modems. The derivatives represent the drivers for many different modem manufacturers and types. Suppose also that you have a requirement to add a new method, named configureForUnix, to the hierarchy. This method will configure the modem to work with the UNIX operating system. The method will do something different in each modem derivative, because each modem has its own particular idiosyncrasies for setting its configuration, and dealing with UNIX.

Unfortunately, adding configureForUnix begs a terrible set of questions. What about Windows, what about OSX, what about Linux? Must we really add a new method to the Modem hierarchy for every new operating system that we use? Clearly, this is ugly. We'll never be able to close the Modem interface. Every time a new operating system comes along, we'll have to change that interface and redeploy all the modem software.

The VISITOR family allows new methods to be added to existing hierarchies without modifying the hierarchies. The patterns^[1] in this family are

^[1] [GOF95]. For Acyclic Visitor and Extension Object, see [PLOPD3].

• VISITOR

• ACYCLIC VISITOR

• DECORATOR

• EXTENSION OBJECT