Visitor pattern 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. Often it is wishful to have multiple operations that can be performed on a set of classes (class hierarchies). Adding these operation directly to the class hierarchy can clutter the code, and makes it very inconvenient to add new operations. Visitor tries to solve this. Participants Visitor: General notion of a visitor Concrete visitor: Specific visit operation, applicable to all target elements. Target: General notation of a visitable element. Concrete target: Specific visitable element Consequences Adding a new operation is easy by gathering related operations and separation unrelated ones No object tests, which leads to better type checking Adding a new concrete element is hard Strategy Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Example: selecting a sorting algorithm on-the-fly Consequences Provides alternative implementation without conditional instruction (e.g. using a parameter to specify the sorting mechanism to be used) Clients must be aware of different strategies Communication overhead between strategy and context Increased number of objects Participants Strategy declares an interface common to all supported algorithms Concrete strategy implements an algorithm Context is configured with a concrete strategy and keeps a reference to a strategy object. Difference to the bridge pattern The bridge pattern and the strategy pattern are very similar. However, their intent is different:
Visitor pattern 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. Often it is wishful to have multiple operations that can be performed on a set of classes (class hierarchies). Adding these operation directly to the class hierarchy can clutter the code, and makes it very inconvenient to add new operations. Visitor tries to solve this. Participants Visitor: General notion of a visitor Concrete visitor: Specific visit operation, applicable to all target elements. Target: General notation of a visitable element. Concrete target: Specific visitable element Consequences Adding a new operation is easy by gathering related operations and separation unrelated ones No object tests, which leads to better type checking Adding a new concrete element is hard Strategy Intent Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. Example: selecting a sorting algorithm on-the-fly Consequences Provides alternative implementation without conditional instruction (e.g. using a parameter to specify the sorting mechanism to be used) Clients must be aware of different strategies Communication overhead between strategy and context Increased number of objects Participants Strategy declares an interface common to all supported algorithms Concrete strategy implements an algorithm Context is configured with a concrete strategy and keeps a reference to a strategy object. Difference to the bridge pattern The bridge pattern and the strategy pattern are very similar. However, their intent is different: