A lot of it's down to a paradigm conflict. In general, if statements are fine. But they're not really considered to be object-oriented. Smalltalk technically doesn't even have an if statement.
I will say that, when I see object-oriented code that branches on the particular subclass of a value at run time, it's often one of the earlier sign that the code is getting messy. Subclassing is supposed to be used for a "don't ask, tell" style of programming. A lot of the problems with OOP that people like to complain about aren't really problems with object-oriented programming, per se; they're problems that crop up when object-oriented and procedural programming are mixed in an uncontrolled manner.
will say that, when I see object-oriented code that branches on the particular subclass of a value at run time, it's often one of the earlier sign that the code is getting messy.
Suppose you have AST which has Node and its various subclasses like ExpressionNode, which then has e.g ConstantExpressionNoee
And so on, many, many other
How would you then avoid branching basing on type?
Comments
A lot of it's down to a paradigm conflict. In general, if statements are fine. But they're not really considered to be object-oriented. Smalltalk technically doesn't even have an if statement.
I will say that, when I see object-oriented code that branches on the particular subclass of a value at run time, it's often one of the earlier sign that the code is getting messy. Subclassing is supposed to be used for a "don't ask, tell" style of programming. A lot of the problems with OOP that people like to complain about aren't really problems with object-oriented programming, per se; they're problems that crop up when object-oriented and procedural programming are mixed in an uncontrolled manner.
Suppose you have AST which has Node and its various subclasses like ExpressionNode, which then has e.g ConstantExpressionNoee
And so on, many, many other
How would you then avoid branching basing on type?