Have you ever noticed? If you say “Hi” to Jay, he replies the same. However Jyoti always replies, “What’s up!”. When you get angry and say “Shut up!”, the reactions are different too. Jay is calm, but firm. His reply is, “Hey, watch your word, buddy!”. But Jyoti loses it and says, “Shut up yourself, dumbo!”

How can two persons interpret the same words differently and react so diversely? Well, chances are that nature has used visitor pattern to program their behaviours that way!

Visitor pattern in real life

Arjun is excellent at the game of frisbee. He can expertly catch a swerving frisbee one-handed even in the swift winds of the beach. However, when it comes to catching a rubber ball, clumsy is the word. The ball bounces off his palms before he can get his fingers around it.
The story is opposite for Bindu. She is extremely quick at judging the direction of a ball thrown high up in the air and can flawlessly complete a good catch. However the swerving direction of a frisbee in the beach wind completely flummoxes her.

As you can see, there is variety in behaviour. For the same object, the behaviour of receiving person is different. For the same person, behaviour with two different objects is different. This diversity in behaviour is the premise of the visitor pattern.

So, what is the visitor pattern?

• The visitor pattern has three parties acting together. These are the client, visitor and the target.
• The client initiates the operations. In the case of beach sports above, you are the one who throws the ball or the frisbee, so you are the client.
• The client asks a target to accept a visitor. Arjun and Bindu are targets asked to accept an incoming sports object. They are the ones who are visited.
• The client releases an object which is called a visitor towards a target. After release, the visitor goes to the target. In beach sports, you release one of two visitors, a ball or a frisbee, towards one of the targets, Arjun or Bindu.
• Depending on the target, a visitor triggers a behaviour. A frisbee visiting Arjun would cause him to catch it, whereas a ball whould cause him to drop it. It is the opposite for Bindu.

The above diagram uses terms like interface, class, object, method, etc. These terms are describe in the post Introduction to object-oriented software. Please read it if you have not already done so or if you have forgotten the terms.

Visitor pattern in software

Taxes are inevitable. Let’s face it. World-over, software bears the brunt of calculating taxes for billions of people. Software eventually gets it right, but for a lot of companies writing the software, it is a big headache to get the formulae correct for every tax bracket. And let’s keep income tax aside for a moment and go to something more complicated: tax on goods and services. Each good or service has its own rules. The rules differ between countries. So image the chagrin of a company that sells its goods and services in multiple countries. Nestle, Gillette or Kellogg’s for instance. Can we make their life easier?

With visitor pattern, we can make their software code easier to maintain and extend. What if we imagine goods and services as visitors? And each country’s tax system as a target? What if we can treat tax calculation like a beach sport and make it more fun? Just like we throw a frisbee to Arjun or a ball to Bindu, we can throw the contents of a virtual shopping cart, say a milk carton, hair clips and power adapters, into a tax system.
A carton of milk thrown at India’s GST (Goods and Services Tax), will cause the GST module to apply a tax of 5%, whereas a packet of butter will cause a 12% tax. We can likewise make the tax system for every country and throw our goods and services at them to get the desired tax calculation behaviour.

Conclusion

Diverse behaviour is a way of life in both the real world and software. When encountered with the same situation, different people / software modules will behave differently. Likewise, the same person / module will behave differently given different situations. Visitor pattern makes it easy to maintain all the behaviour and even create new behaviour when more people / module or situations are added.