instanceof versus polymorphism

Question

I am having troubles with the instanceof operator. I'm trying to avoid it. Basically, I have the following structure:

class Shape {}
class Triangle extends Shape {}
class Rectangle extends Shape {}

ShapeParser s;
while (s.hasNext())
     parseShape(s.next()); // returns a Shape object

void parseShape(Triangle t) { // do stuff } // KEY POINT HERE
void parseShape(Rectangle t) { // etc }

The key point I'm making is: I want to do a parameter overload of the function, but it's not working as I intend it to (compile-error). I am trying to avoid:

void parseShape(Shape s)
{
     if (s instanceof Triangle) ...
}

UPDATE: it seems that the consensus is to create a base class method: parseShape() to do the lifting. I wanted to clarify my question: the motivation of this question is relative to the observer pattern. Suppose I have the following Observer object payload method:

    public void update(Observable obj, Shape objectPayload){} 
// note: the objectPayload is usually of type Object

Instead of performing:

public void update(Observable obj, Shape objectPayload)
{
       if (objectPayload instanceof Triangle)
          // do stuff
       else if (objectPayload instanceof Rectangle)
          // etc
}

I want to do:

public void update(Observable obj, Shape objectPayload)
{
       parseShape(objectPayload);
}

    void parseShape(Triangle t) {  } // do stuff
    void parseShape(Rectangle t) { }

No, no, a hundred times no! Don't make me come over there and slap you around :-) In OO, the _object/class_ is god. If you find yourself in the situation where _code_ is once again becoming the primary thing, you're reverting to the pre-OO days. Even the observer pattern should follow this rule: ... notifies them automatically of any state changes, _usually by calling one of their methods._ — paxdiablo, May 25 '11 at 03:33
Looks more and more like you want the visitor pattern. See, for example, [this thread](http://stackoverflow.com/questions/944824/visitor-pattern-implementation-in-java-how-does-this-look). Put that once into your Shape hierarchy and you won't need to pollute that hierarchy with parsing code, or code for any other operation you want to apply similarly. — Ted Hopp, May 25 '11 at 03:43

Jérôme Verstrynge · Answer 1 · 2011-05-25T03:10:31.300

4

If your parseShape() method were declared in Shape, it could be overridden in Triangle and Rectangle.

That is:

ShapeParser s;
while (s.hasNext())
     // Calls the proper implementation of parseShape()
     s.next().parseShape();

edited May 25 '11 at 03:10

answered May 25 '11 at 03:07

Jérôme Verstrynge

57,710
92
283
453

+1. This is the correct OO way of doing it. Use of `instanceof` should usually be a tar-and-feather offence in your code reviews :-) – paxdiablo May 25 '11 at 03:08
Your sort of turn the world inside out, and then it falls into place. +1 on tar-and-feather. – Chris May 25 '11 at 03:13

score 4 · Accepted Answer · edited May 23 '17 at 11:43

You can move the parseShape into each Shape class. Alternatively, you can use the Visitor pattern. There's a neat trick with reflection shown in the solution to this thread that avoids the complexity of a full visitor pattern in Java.

UPDATE:

Here's a recipe for the visitor pattern:

Declare an interface:

public interface ShapeVisitor {  
    visit(Triangle);  
    visit(Rectangle);  
    // ...  
}

In Shape, declare an abstract method acceptVisitor:

class Shape {
    public abstract void acceptVisitor(ShapeVisitor visitor);
}

In each concrete class, implement acceptVisitor:

class Triangle extends Shape {
    public void acceptVisitor(ShapeVisitor visitor) {
        visitor.visit(this);
    }
}

Declare your ParseVisitor class to implement ShapeVisitor and implement all the required methods (simply rename each of the parseShape methods to visit).

The nice things about this are, first, it keeps the parsing code out of your Shape hierarchy and centralizes it in a separate parsing class; second, if you later decide that you need to do some other operation (like, say, render), you can apply the same pattern without ever changing any Shape class. The big down side of this approach is that you will have to change all classes that implement ShapeVisitor if you decide to add another Shape subclass.

score 1 · Answer 3 · answered May 25 '11 at 03:08

1

Um, add a parse method to the base class then just loop and iterate through the list of shapes and call s.parse()?

answered May 25 '11 at 03:08

Rob

11,446
7
39
57

score 0 · Answer 4 · answered May 25 '11 at 03:11

0

I assume that the error is because s.next() returns Shape. Logical thing would be to add parse() method to shape and call s.parse()

answered May 25 '11 at 03:11

Alex Gitelman

24,429
7
52
49

instanceof versus polymorphism

4 Answers4

Linked