xgillard
commented
3 years ago Here are a few cool examples that would be better fits for visitor:
- University management system.
One can expect to have the following objects defined:- Faculties
- Departments
- Technical/Support personnel
- Teaching staff
- Researchers
- Students
- Building
- Classes
- Courses
- Computers
- .. whatever machinery you like and more
There are many tasks which one might want to define on those:
- Define the budget of the Univ. (positive income for students, negative for staff and resources)
- Prepare candidate time tables for examinations (a class that can accomodate the students of a particular course).
- Prepare the payroll
- ...
- An other maybe more fun example of use for Visitor When implementing a videogame, you're likely to use an ECS (entity component system). Depending on the moment of the day and the material of each entity in the system, the rendering engine might need to paint the same objects in various colors at different moment of time.
A convenient approach to that would be to let the 'renderer' system pick the painting algo. (whichone implements visitor) based on the time of the day and wheather conditions (those are entities that can be queries from the ECS, but we'll assume they're just given parameters). The chosen painting sub-service would then visit all the visible physical entities of the scene (visited entity decides whether it is visible or not) and paint them according to the appropriate color scheme.
This issue relates to #35 (should probably be a subtask of it).
This exercise is a wrong use case of the visitor pattern. The appropriate pattern to use here is the Interpreter pattern. While it is true that one can implement a grammar-like interpretation with a visitor, this is pretty artificial and forces to break encapsulation. (Encapsulation breakage is the major inconvenient of Visitor pattern and built in it).
An exercise about the visitor pattern should start by recalling what double dispatch is and provide an example that requires it.