The Visitor pattern is a behavioral pattern for adding an operation to existing objects without changing their classes. Keep the objects and their operations separate when several operations must act on the same object structure, making new behavior easier to add. section 3.3 section 3.4
Model the pattern with four collaborating roles:
- Element declares an accept method that receives a visitor. section 3.3
- Concrete elements implement or extend Element and represent object types in the structure. section 3.3
- Visitor declares a visit method for each concrete element type. section 3.3
- Concrete visitors implement those visit methods and contain the algorithm applied to each element. section 3.3
Use the pattern when assets need several independent calculations. Rather than placing every calculation on Asset, pass a visitor to the asset and let the visitor hold the operation’s state. This keeps cost, depreciation, and allocation reporting logic outside the asset model. section 3.3 section 4.2.1
Department statistics visitor
A DepartmentVisitor defines visit(asset). DepartmentStatisticsVisitor initializes total cost, depreciation, and allocation to zero; each visit adds values obtained from the asset, and getter methods return the accumulated totals. This is a focused implementation to generate and then review in an IT asset-management design. section 4.2.1
Figure 4.7 The DepartmentVisitor interface (updated to use the new name; previously called LineOfBusinessVisitor). This class “visits” both hardware and software, holding the total cost and depreciation internally.
Inspect the interface and its relationship to hardware and software: the visitor retains total cost and depreciation while visiting both asset types. section 4.2.1
Generated pattern code is a starting point, not a design decision made for you. Check that the visitor’s operations match the reporting need, that assets expose the values being totaled, and that the generated implementation fits the evolving model before adopting it. section 3.3 section 4.2.1
