Code: Alles auswählen
/*EXERCISE PRIVATE-PART*/@OCP(Compliancy.Violated)
public interface ExpressionVisitor<T> {
T visit(Constant c);
T visit(Var var);
T visit(BinaryExpression b);
T visit(UnaryExpression u);
}
Moderatoren: pmueller, SE - Design and Construction
Code: Alles auswählen
/*EXERCISE PRIVATE-PART*/@OCP(Compliancy.Violated)
public interface ExpressionVisitor<T> {
T visit(Constant c);
T visit(Var var);
T visit(BinaryExpression b);
T visit(UnaryExpression u);
}
On the other hand, if I remember correctly, this class was considered OCP compliant at first, but the solution was changed after some discussion. (Refer to this announcement.) So it probably depends on the argumentation and as always on the dimenson of extension.3. Adding new ConcreteElement classes is hard. The Visitor pattern makes it hard to add new subclasses of Element. Each new ConcreteElement gives rise to a new abstract operation on Visitor and a corresponding implementation in every ConcreteVisitor class. Sometimes a default implementation can be provided in Visitor that can be inherited by most of the ConcreteVisitors, but this is the exception rather than the rule.
So the key consideration in applying the Visitor pattern is whether you are mostly likely to change the algorithm applied over an object structure or the classes of objects that make up the structure. The Visitor class hierarchy can be difficult to maintain when new ConcreteElement classes are added frequently. In such cases, it's probably easier just to define operations on the classes that make up the structure. If the Element class hierarchy is stable, but you are continually adding operations or changing algorithms, then the Visitor pattern will help you manage the changes.