Visitor Pattern

Design Patterns
1

Why use an interface for the htmlNode class and not instead an abstract class with the implementation for the execute method?
So you can extend the abstract htmlNode class and have the logic from the execute method?

2

Because of the way this pattern works, you cannot have the logic of the execute method in the abstract class. Why? Because of the method signatures (which is tied to how the actual pattern works).

The Operation interface has one apply method per concrete type (so one for HeadingNode and one for AnchorNode), but it does not have an apply method typed to the HtmlNode interface. So you cannot have the following compile inside an HtmlNode implemented as an abstract class:

public abstract class HtmlNode {
  public void execute(Operation operation) {
    // "this" is typed to HtmlNode, so this code does not compile
    operation.apply(this);
  }
}

Even though the concrete classes have the same lines of code, they are actually quite different because they are calling different methods on the interface. Adding some comments for clarity:

public class HeadingNode implements HtmlNode {
  @Override
  public void execute(Operation operation) {
    // "this" is typed to HeadingNode so we can call Operation.apply(HeadingNode hn)
    operation.apply(this);
  }
}

public class AnchorNode implements HtmlNode {
  @Override
  public void execute(Operation operation) {
    // "this" is typed to AnchorNode so we can call Operation.apply(AnchorNode an)
    operation.apply(this);
  }
}

Having the Operation interface with methods typed to the concrete classes is exactly how the Visitor pattern works so you practically have to use interfaces here.