CODEWITHSUNDEEP
design-patternsvisitor-pattern
Jomy George
Jomy George

Reputation: 323

Visitor pattern

When i read about visitor pattern it says like

Allows for one or more operation to be applied to a set of objects at run-time, decoupling the operations from the object structure.

If my assumption is correct, we will define an abstract visitor which holds methods for treating each Objects. Then concrete visitor will implement each of these methods. By this we are separating the logic of handling objects from Object class to visitor implementation.

My doubt is if we have only one visitor implementation, do we really need to use this pattern? can't we just place the implementation in each Object class and call it directly? Please correct me if i miss something in between.

Upvotes: 4

Views: 516

Answers (3)

JuanZe
JuanZe

Reputation: 8157

Actually you never really need to use this pattern or any other pattern. If you are using patterns is because you are making a design choice based on your context.

Several items of the pattern documentation are aimed to help you make and informed decision about using the pattern or not. In particular, check these sections:

  • Intent: A description of the goal behind the pattern and the reason for using it.
  • Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used.
  • Applicability: Situations in which this pattern is usable; the context for the pattern.
  • Consequences: A description of the results, side effects, and trade offs caused by using the pattern.

If you are in a context when you benefit from decoupling operations from the object structure, may be because in the future there will be new operations to apply to those objects, the pattern will improve your design. If you are in a context of a small program with a limited life span the pattern could be an overhead.

So read again the pattern documentation, check your software context and make and informed decision about using it or not.

Upvotes: 4

sanderarts
sanderarts

Reputation: 334

Your description of the Visitor pattern says it all:

Decoupling operations from the object structure

In a well decoupled world, you would have objects that hold data and object that operate on data. The goal of the Visitor pattern is to decouple these. It is probably not a pattern you'll will see often explicitly, however the underlying principal you'll see everywhere.

By decoupling operations you use the O in SOLID (Open/Closed Principle) which states that you can change its behaviour without changing the source code. Because if you would like to have new/remove/change operations on your object, you just add/remove/change a visitor of this object instead of the object itself.

Upvotes: -1

JB Nizet
JB Nizet

Reputation: 691685

I disagree.

It's not always possible or desirable to put the logic inside the object rather than putting it inside a visitor. For example, a persistent entity (a User, or an Order), part of the "domain" layer, doesn't necessarily have access (or shouldn't have access) to the services (part of the "service" layer) that are necessary to execute the operation: bill the order, or promote the user.

Also, just because there is only one visitor now doesn't mean that others won't appear later.

The goal of the pattern is decoupling. By putting the operation in the visited object itself, you don't have decoupling anymore.

By decoupling, you're also creating a reusable API. The developer using your classes might very well be unable to modify them, because he/she simply doesn't have the source code and thus can't change it. Yet it must be able to do something different depending on the actual concrete class of the object. Hence the visitor pattern.

Upvotes: 1

Related Questions