From Wikipedia :
The idea was that once completed, the implementation of a class could only be modified to
correct errors; new or changed features would require that a different class be created.
That class could reuse coding from the original class through inheritance
From what I understand, The Visitor pattern is a powerful technique to traverse similar but different objects that implement the same Interface by the use of double dispatch. In one of my Java examples, I created a composite set of objects that form a tree structure, and each specific implementation of those objects implement the visitable interface. The visitor interface has a method for each of the visitable objects, and the concrete visitor implements what to do for each of those cases.
The thing I’m trying to get my head around is the fact that if I were to add a new implementation to the composite structure that also implements visitable, then I need to reopen the visitor interface and add that case to it, also forcing me to modify each implementation of visitor.
While this is fine, since I would need to do this anyway (What good is adding to your visitables if the visitor can’t understand them?) but on an academic level, wouldn’t this be violating the Open Closed Principle? Isn’t that one of the core reasons for Design Patterns anyway? Trying to show a decent reason for switching to this pattern instead of maintaining a switch statement to end all switch statements, but everyone argues that the code will be the same anyways, with a method for each case instead of a switch block, just broken up and harder to read.
A pattern is applicable to certain cases. From the GoF book (p. 333):
If you frequently change the classes of the objects that make up the structure, the Visitor class hierarchy can be hard to maintain. In such a case, it may be easier to define operations on the classes that make up the structure.