In the software world, the Visitor patterns helps you prevent code bloat in class hierarchies, typically. Consider a class hierarchy of parts. There are many subclasses of parts like resistor, capacitor etc. Initially, the classes have only their fundamental operations in their code. But, sooner or later, we want to do more operations like expose the part details in XML format, for example.

A naive approach would add the XML conversion operation to all the classes in the class hierarchy. If another such requirement comes about, we need to add those operations again in all the classes. This is painful for many reasons:

1. The existing classes are stable and well-tested. Adding more methods by modifying them makes them unstable. All the testing has to be done again.
2. There is code bloat in these classes and this affects the readability of the classes.
3. The classes, now, no longer expose simple and orthogonal operations.

The visitor pattern alleviates this pain, by putting such non-fundamental operations in a single place outside the class hierarchy. The classes would be changed only once, to add an "accept()" method that accept an abstract visitor object. This method implementation would turn around and callback the "visitConcreteObject()" and pass itself (this) as the parameter. This is called double callback. For details of the implementation, refer to the GoF book.

In the above example, all the parts would have a method, say,

accept(AbstractVisitor avisitor)

public class Resistor {

  public void accept(AbstractVisitor avisitor) {
    avisitor.visitResistor(this);
  }
}

Now, the XML Outputter class will be a subclass of the AbstractVisitor and would like this:

public class XMLOutputVisitor extends AbstractVisitor {

  public void visitResistor(Resistor r) {
  ...
  }

  public void visitCapacitor(Capacitor c) {
  ... 
  }
 
  ...

}

Please note that all the XMLOutput related code is in one place and if that requirement changes (to use SAX instead of DOM, for example), the code change is all in one place.

Also note that the visitor pattern is a good fit only if the the class hierarchy itself is stable. If a new type of part is added (say, a PCB) ALL the visitors have to change to add a method.