I have a composite object (I will call it
A) that has fixed number of sons (I will call them
All of them have an
I have a GUI,
A is the main window that consists of many sub-windows (a.k.a
The visitors will be visitors for when a user clicks a button to start a new operation such as starts a new game, guesses a word incorrectly and other events. (
Command design pattern is used, but this is out of the scope) and when such events happends the visitor will update the GUI appropriately.
When considering how to implement
A, I consider weather I should cascade the
Accept(Visitor) request to
A2 as well or not.
Here is my argument for cascading:
More transparency – in all of my visitors until now, I do want to go over the sons of
A. but in order to do that without cascading, I will need getters for the sons of
A, but the sons of
A can change (even at run time, if I change implementation from fixed amount of sons to a collection) and I do not wish to change the interface all the time to support such get operations. You might suggest iterators for that, but the thing is that the Visitor might want to visit
A2, but if another
A3 son will be added, he might not want to visit it. So as it iterates through
A‘s sons, it will must resort to ugly type checking, which is what the Visitor design pattern has come to eradicate. Instead, it might be much easier to simply cascade all the requests to the children, and if a visitor isn’t interested in visiting some type, it cant just leave the visit method for it empty. Moreover, in the symbolic level,
A2 are part of
A, so the cascade makes sense.
Here is my argument against cascading:
Looser coupling – cascading means you force the visitor to visit children it might didn’t want to visit, which can lead to unexpected results. Moreover, it might not support accepting the types of the children. If getter or iterators are used, then the visitor can choose weather it wants to go over the children.
What approach should I take?