Polymorphism and casting

Question

Hi there, I would be grateful if I could get some help on the following:
I am writing an application that dynamically processes diferent shapes (e.g. line, circle, rectangle) using a number of algorithms (algorithmA, algorithmB, algorithmC etc).
Therefore, I have defined an abstract superclass called Shape and the subclasses Line, Circle, and Rectangle. I have also difined an abstract superclass called ShapeProcessor and a number of subclasses, ShapeProcessorA, ShapeProcessorB, ShapeProcessorC... Each shapeProcesssor class has overloaded member methods (called processShape) to process each shape type. So my ShapeProcessor class looks like:
public abstract class ShapeProcessor{
     public abstract void processShape(Line aLine);
     public abstract void processShape(Circle aCircle);
     public abstract void processShape(Rectangle aRectangle);
For instance, if I want to process a cirlce using the algorithm B I can write something like:
ShapeProcessor aShapeProcessor= new ShapeProcessorB();
aShapeProcessor.processShape(new Circle());
My problem is when I have an array of Shape objects which I need to process. Before I can pass each shape to the processShape method I need to cast it first (i.e. to convert them from the abstract superclass Shape into a particular shape, Circle, Rectangle etc).
A crude way of doing that it will be to retrieve the "Class" of each shape and use a switch statement to cast each shape. However, this is not what Object-Orientation is all about. Is there any better approach?
best regards,
Kyri.

Answer 1

If you make the superclass method definition abstract,
then once again you get the benefit of compile-time
checking, no matter how many classes you add.I'm not sure I understand what you mean by this.
Let's take mattbunch's approach, where a ProcessableShape calls a method in ShapeProcessor. If I understand what you're saying, you would have that method be abstract. We could also define ShapeProcessor as an interface, like so:
    public interface ShapeProcessor
        void processShape(Line shape);
        void processShape(Circle shape);
        void processShape(Ellipse shape);
    }OK, here we have our "case" statement, represented by separate methods in the interface. The ProcessableShape subclass calls processShape, passing itself as the argument, and the compiler picks the appropriate method. Each implementation of ShapeProcessor needs to implement all the methods for defined by the interface.
The problem comes when you change the definition of ShapeProcessor but don't recompile all your implementations. This is pretty easy to do with javac, because there isn't necessarily a direct dependency. You can of course overcome the problem with a rigorous build process.
However, if your builds do get out of sync, your app is going to blow up. Perhaps not right away, perhaps not until you happen to process the unsupported shape. But because Java does dynamic, as-needed binding, the possibility will be there.
This isn't a Java-specific problem. I suspect that it would happen with DLLs, and know that it happens with UNIX shared libraries. The key to avoiding it is to eliminate unnecessary interdependencies, especially (in my experience) between work and worker objects.
And, to head off the obvious critique: yes, there are times that you can't avoid such dependencies. I suspect the OP's original design was one of those times. But if by changing the design slightly, the dependencies could be eliminated, you have a better design.