Files
abstract-factory
adapter
async-method-invocation
bridge
builder
business-delegate
callback
chain
chain-of-responsibility
command
composite
dao
decorator
dependency-injection
double-checked-locking
double-dispatch
event-aggregator
execute-around
facade
factory-method
flux
flyweight
front-controller
half-sync-half-async
intercepting-filter
interpreter
introduction
iterator
layers
lazy-loading
mediator
memento
model-view-controller
model-view-presenter
multiton
naked-objects
null-object
object-pool
observer
poison-pill
private-class-data
property
prototype
proxy
repository
resource-acquisition-is-initialization
servant
service-layer
service-locator
singleton
specification
state
step-builder
strategy
template-method
thread-pool
tolerant-reader
visitor
etc
src
index.md
pom.xml
.gitignore
.travis.yml
LICENSE.md
README.md
pom.xml
java-design-patterns/visitor/index.md

25 lines
1.6 KiB
Markdown
Raw Normal View History

---
layout: pattern
title: Visitor
folder: visitor
permalink: /patterns/visitor/
categories: pattern_cat
tags: pattern_tag
---
**Intent:** Represent an operation to be performed on the elements of an object
structure. Visitor lets you define a new operation without changing the classes
of the elements on which it operates.
![alt text](./etc/visitor_1.png "Visitor")
**Applicability:** Use the Visitor pattern when
* an object structure contains many classes of objects with differing interfaces, and you want to perform operations on these objects that depend on their concrete classes
* many distinct and unrelated operations need to be performed on objects in an object structure, and you want to avoid "polluting" their classes with these operations. Visitor lets you keep related operations together by defining them in one class. When the object structure is shared by many applications, use Visitor to put operations in just those applications that need them
* the classes defining the object structure rarely change, but you often want to define new operations over the structure. Changing the object structure classes requires redefining the interface to all visitors, which is potentially costly. If the object structure classes change often, then it's probably better to define the operations in those classes
**Real world examples:**
* [Apache Wicket](https://github.com/apache/wicket) component tree, see [MarkupContainer](https://github.com/apache/wicket/blob/b60ec64d0b50a611a9549809c9ab216f0ffa3ae3/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java)