Паттерн visitor java пример

Visitor Pattern Tutorial with Java Examples

Join the DZone community and get the full member experience.

Today we’re going to take a look at the Visitor pattern. Of all of the patterns that I’ve used so far, Visitor is by far the most powerful and convenient.

Vistors in the Real World

A real world analogy always helps with the understanding of a design pattern. One example I have seen for the Visitor pattern in action is a taxi example, where the customer calls orders a taxi, which arrives at his door. Once the person sits in, the visiting taxi is in control of the transport for that person.

Shopping in the supermarket is another common example, where the shopping cart is your set of elements. When you get to the checkout, the cashier acts as a visitor, taking the disparate set of elements (your shopping), some with prices and others that need to be weighed, in order to provide you with a total.

It’s a difficult pattern to explain in the real world, but things should become clearer as we go through the pattern definition, and take a look at how to use it in code.

Design Patterns Refcard
For a great overview of the most popular design patterns, DZone’s Design Patterns Refcard is the best place to start.

The Visitor Pattern

The Visitor is known as a behavioural pattern,as it’s used to manage algorithms, relationships and responsibilities between objects. Thedefinition of Visitor provided in the original Gang of Four book on DesignPatterns states:

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

What the Visitor pattern actually does is create an external class that uses data in the other classes. If you need to perform operations across a dispate set of objects, Visitor might be the pattern for you. The GoF book says that the Visitor pattern can provide additional functionality to a class without changing it. Let’s see how that can work, first by taking a look at the classic diagram definition of the Visitor pattern:

The core of this pattern is the Visitor interface. This interface defines a visit operation for each type of ConcreteElement in the object structure. Meanwhile, the ConcreteVisitor implements the operations defined in the Visitor interface. The concrete visitor will store local state, typically as it traverses the set of elements. The element interface simply defines an accept method to allow the visitor to run some action over that element — the ConcreteElement will implement this accept method.

Where Would I Use This Pattern?

The pattern should be used when you have distinct and unrelated operations to perform across a structure of objects. This avoids adding in code throughout your object structure that is better kept seperate, so it encourages cleaner code. You may want to run operations against a set of objects with different interfaces. Visitors are also valuable if you have to perform a number of unrelated operations across the classes.

In summary, if you want to decouple some logical code from the elements that you’re using as input, visitor is probably the best pattern for the job.

So How Does It Work In Java?

The following example shows a simple implementation of the pattern in Java. The example we’ll use here is a postage system. Our set of elements will be the items in our shopping cart. Postage will be determined using the type and the weight of each item, and of course depending on where the item is being shipped to.

Let’s create a seperate visitor for each postal region. This way, we can seperate the logic of calculating the total postage cost from the items themselves. This means that our individual elements don’t need to know anything about the postal cost policy, and therefore, are nicely decoupled from that logic.

First, let’s create our general visitable interface:

//Element interface public interface Visitable

Now, we’ll create a concrete implementation of our interface, a Book.

//concrete element public class Book implements Visitable < private double price; private double weight; //accept the visitor public void accept(Visitor vistor) < visitor.visit(this); >public double getPrice() < return price; >public double getWeight() < return weight; >> 

As you can see it’s just a simple POJO, with the extra accept method added to allow the visitor access to the element. We could add in other types here to handle other items such as CDs, DVDs or games.

Now we’ll move on to the Visitor interface. For each different type of concrete element here, we’ll need to add a visit method. As we’ll just deal with Book for now, this is as simple as:

The implementation of the Vistor can then deal with the specifics of what to do when we visit a book.

public class PostageVisitor implements Visitor < private double totalPostageForCart; //collect data about the book public void visit(Book book) < //assume we have a calculation here related to weight and price //free postage for a book over 10 if(book.getPrice() < 10.0) < totalPostageForCart += book.getWeight() * 2; >> //add other visitors here public void visit(CD cd) public void visit(DVD dvd) //return the internal state public double getTotalPostage() < return totalPostageForCart; >> 

As you can see it’s a simple formula, but the point is that all the calculation for book postage is done in one central place.

To drive this visitor, we’ll need a way of iterating through our shopping cart, as follows:

public class ShoppingCart < //normal shopping cart stuff private ArrayListitems; public double calculatePostage() < //create a visitor PostageVisitor visitor = new PostageVisitor(); //iterate through all items for(Visitable item: items) < item.accept(visitor); >double postage = visitor.getTotalPostage(); return postage; > >

Note that if we had other types of item here, once the visitor implements a method to visit that item, we could easily calculate the total postage.

So, while the Visitor may seem a bit strange at first, you can see how much it helps to clean up your code. That’s the whole point of this pattern — to allow you seperate out certain logic from the elements themselves, keeping your data classes simple.

Watch Out for the Downsides

The arguments and return types for the visiting methods needs to be known in advance, so the Visitor pattern is not good for situtations where these visited classes are subject to change. Every time a new type of Element is added, every Visitor derived class must be amended.

Also, it can be difficult to refactor the Visitor pattern into code that wasn’t already designed with the pattern in mind. And, when you do add your Visitor code, it can look obscure. The Visitor is powerful, but you should make sure to use it only when necessary.

Next Up

Later on this week, we’re going to visit the Proxy pattern.

Enjoy the Whole «Design Patterns Uncovered» Series:

Creational Patterns

Structural Patterns

Behavioral Patterns

• Learn The Chain of Responsibility Pattern
• Learn The Command Pattern
• Learn The Interpreter Pattern
• Learn The Iterator Pattern
• Learn The Mediator Pattern
• Learn The Memento Pattern
• Learn The Observer Pattern
• Learn The State Pattern
• Learn The Strategy Pattern
• Learn The Template Method Pattern
• Learn The Visitor Pattern

Opinions expressed by DZone contributors are their own.

Источник

Visitor Design Pattern Example

Design patterns are used to solve the problems which occur in a pattern, we all know that, right? Also we know that behavioral design patterns are design patterns that identify common communication patterns between objects. One of such behavioral patterns is visitor pattern, which we are going to learn about in this post.

If you have been in working on a application which manage plenty of products, then you can easily relate with this problem:

“You need to add a new method to a hierarchy of classes, but the act of adding it might be painful or damaging to the design.”

So clearly, you want a hierarchy of objects to modify their behavior but without modifying their source code. How to do that? To solve this problem, visitor pattern comes into picture.

Sections in this post: Visitor pattern introduction Design participants/components Sample problem to solve Proposed solution using Visitor pattern Implementation code How to use visitors in application code Sourcecode download

Visitor pattern introduction

According to Wikipedia, the visitor design pattern is a way of separating an algorithm from an object structure on which it operates. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures. It is one way to follow the open/closed principle (one of SOLID design principles).

Above design flexibility allows to add methods to any object hierarchy without modifying the code written for hierarchy. Rather double dispatch mechanism is used to implement this facility. Double dispatch is a special mechanism that dispatches a function call to different concrete functions depending on the runtime types of two objects involved in the call.

The participants classes in this pattern are:

Visitor – This is an interface or an abstract class used to declare the visit operations for all the types of visitable classes.

ConcreteVisitor – For each type of visitor all the visit methods, declared in abstract visitor, must be implemented. Each Visitor will be responsible for different operations.

Visitable – is an interface which declares the accept operation. This is the entry point which enables an object to be “visited” by the visitor object.

ConcreteVisitable – Those classes implements the Visitable interface or class and defines the accept operation. The visitor object is passed to this object using the accept operation.

An example is always better than long theory. So let’s have one here also for visitor design pattern.

Suppose we have an application which manage routers in different environments. Routers should be capable of sending and receiving char data from other nodes and application should be capable of configuring routers in different environment.

Essentially, design should flexible enough to support the changes in way that routers can be configured for additional environments in future, without much modifications in source code.

We have above 3 types of routers and we need to write code for them. One way to solve this problem, is to define methods like configureForWinodws() and configureForLinux() in Router.java interface and implement them in different products, cause each will have it’s own configuration setting and procedure.

But the problem with above approach is that each time a new environment is introduced, whole router’s hierarchy will have to be compiled again. Not acceptable solution. So what is it which can prevent this situation?

Proposed solution using Visitor pattern

Visitor pattern is good fit for these types of problems where you want to introduce a new operation to hierarchy of objects, without changing its structure or modifying them. In this solution, we will implement double dispatch technique by introducing two methods i.e. accept() and visit() methods. Method accept(), will be defined in router’s hierarchy and and visit methods will be on visitors level.

Whenever a new environment need to be added, a new visitor will be added into visitors hierarchy and that needs to implement visit() method for all the available routers and that’s all.

In above class diagram, we have routers configured for Mac and Linux operating systems. If we need to add the capability for windows also, then I do not need to change any class, just define a new visitor WindowsConfigurator and implement the visit() methods defined in RouterVisitor interface. It will provide the desired functionality without any further modification.

Let’s look at the source code of different files involved into above discussed problem and solution.

DLinkRouter.java

public class DLinkRouter implements Router < @Override public void sendData(char[] data) < >@Override public void acceptData(char[] data) < >@Override public void accept(RouterVisitor v) < v.visit(this); >>

LinkSysRouter.java

public class LinkSysRouter implements Router < @Override public void sendData(char[] data) < >@Override public void acceptData(char[] data) < >@Override public void accept(RouterVisitor v) < v.visit(this); >>

TPLinkRouter.java

public class TPLinkRouter implements Router < @Override public void sendData(char[] data) < >@Override public void acceptData(char[] data) < >@Override public void accept(RouterVisitor v) < v.visit(this); >>

RouterVisitor.java

public interface RouterVisitor

LinuxConfigurator.java

public class LinuxConfigurator implements RouterVisitor < @Override public void visit(DLinkRouter router) < System.out.println("DLinkRouter Configuration for Linux complete !!"); >@Override public void visit(TPLinkRouter router) < System.out.println("TPLinkRouter Configuration for Linux complete !!"); >@Override public void visit(LinkSysRouter router) < System.out.println("LinkSysRouter Configuration for Linux complete !!"); >>

MacConfigurator.java

public class MacConfigurator implements RouterVisitor < @Override public void visit(DLinkRouter router) < System.out.println("DLinkRouter Configuration for Mac complete !!"); >@Override public void visit(TPLinkRouter router) < System.out.println("TPLinkRouter Configuration for Mac complete !!"); >@Override public void visit(LinkSysRouter router) < System.out.println("LinkSysRouter Configuration for Mac complete !!"); >>

How to use visitors in application code

To use above design, use the visitors in below given way. I have used the code in form of JUNIT testcases, you can change the code the way you feel correct into your case.

TestVisitorPattern.java

public class TestVisitorPattern extends TestCase < private MacConfigurator macConfigurator; private LinuxConfigurator linuxConfigurator; private DLinkRouter dlink; private TPLinkRouter tplink; private LinkSysRouter linksys; public void setUp() < macConfigurator = new MacConfigurator(); linuxConfigurator = new LinuxConfigurator(); dlink = new DLinkRouter(); tplink = new TPLinkRouter(); linksys = new LinkSysRouter(); >public void testDlink() < dlink.accept(macConfigurator); dlink.accept(linuxConfigurator); >public void testTPLink() < tplink.accept(macConfigurator); tplink.accept(linuxConfigurator); >public void testLinkSys() < linksys.accept(macConfigurator); linksys.accept(linuxConfigurator); >> Output: DLinkRouter Configuration for Mac complete !! DLinkRouter Configuration for Linux complete !! LinkSysRouter Configuration for Mac complete !! LinkSysRouter Configuration for Linux complete !! TPLinkRouter Configuration for Mac complete !! TPLinkRouter Configuration for Linux complete !!

Sourcecode download

To download the sourcecode of above application, follow given link.

Happy Learning !!

Источник