Pattern two in this series will be the visitor pattern. Why? Well, I was asked about it a few months back and I couldn’t remember its finer points. After this post, I will be much better able to answer the same question if it arises at my next pattern party 🙂
The main ‘components’ of this pattern are as follows:
- An interface that allows each unrelated class to be ‘visited’. In my example, this is IAcceptVisitor.js.
- Each unrelated class implements this interface so it can accept the accepting visitor.
NOTE: This is the ‘tie’ between the visitor and the unrelated class. It is small, but it is still a dependency which I am not wild about.
- An interface for the visitor. In my example, this is Ivisit.js. I have one visitor that ‘visits’ every class that will accept it.
NOTE: I amended this after the commit to take a system and not a group and name.
- A concrete implementation for the visitor that goes to each unrelated class/object. In my example, this is SystemVisitor.js
All of this is put together in visitor.js (a driver file of sorts).