Take the 2-minute tour ×

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)

    void parseShape(Triangle t) {  } // do stuff
    void parseShape(Rectangle t) { }
share|improve this question
Please post the error... –  phooji May 25 '11 at 3:06
And why is your rectangle called t? :-) –  paxdiablo May 25 '11 at 3:12
Updated question; please see. –  Carlo del Mundo May 25 '11 at 3:25
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 3:33
Looks more and more like you want the visitor pattern. See, for example, this thread. 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 3:43
add comment

4 Answers

up vote 4 down vote accepted

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.


Here's a recipe for the visitor pattern:

  1. Declare an interface:

    public interface ShapeVisitor {  
        // ...  
  2. In Shape, declare an abstract method acceptVisitor:

    class Shape {
        public abstract void acceptVisitor(ShapeVisitor visitor);
  3. In each concrete class, implement acceptVisitor:

    class Triangle extends Shape {
        public void acceptVisitor(ShapeVisitor visitor) {
  4. 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.

share|improve this answer
Thanks this is what I was looking for. –  Carlo del Mundo May 25 '11 at 14:17
add comment

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()
share|improve this answer
+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 3: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 3:13
add comment

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

share|improve this answer
add comment

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()

share|improve this answer
add comment

Your Answer


