在这种情况下如何避免instanceof运算符

Question

I'm writing simple game with cells which can be in two states Free and Taken by player.

interface Cell {
    int posX();
    int posY();
}

abstract class BaseCell implements Cell {

    private int x;
    private int y;

    public int posX() {
        return x;
    }

    public int posY() {
        return y;
    }

    ...
}

class FreeCell extends BaseCell {
}

class TakenCell extends BaseCell {
    private Player owningPlayer

    public Player owner() {
        return owningPlayer;
    }

}

In each turn I need to inspect all cells to calculate next cell state with method as below

// method in class Cell
public Cell nextState(...) {...}

and collect (in Set ) all cells that are not yet taken. The method above returns Cell because cell may change from Free to Taken or the opposite. I'm doing something like below to collect them:

for (Cell cell : cells) {
    Cell next = cell.futureState(...);
    if(next instanceof FreeCell) {
        freeCells.add(currentCell);
    }
    ...
}

It's ugly. How to do that to avoid such instanceof hacks? I'm not talking about another hack, but would like to find out proper OOP solution.

Answer 1

It sounds like you are flirting with the "State" pattern but you are not quite there. Using the state pattern you would have your Cell object and a hierarchy of "Cell State" classes.

The Cell object would use composition rather than inheritance. In other words, a Cell would have a current state property. When you have a Cell where the currentState property is a FreeState object then it's a free cell. When you have a Cell where the currentState property is a TakenState object, then it's a free state.

How to do that to avoid such instanceof hacks?

Whenever you have a situation where you would need to do an instanceof, you add a method to your Cell class and just invoke it. The Cell delegates to the current state. The code in Cell which delegates to the current state does not actually know what the state is. It just trusts that the state will do the right thing. In your FreeState and TakenState you provide implementations of each method that do the right thing based on their state.

Answer 2

I think the design problem here is that you have two different classes for what can be essentially two different states of the same cell.

What do you do now when a previously free cell becomes occupied? Create a new object with same coordinates and discard the old one? But it's still the same cell conceptually! (Or can there be a free cell and a taken cell with same x and y at the same time?)

From the OOP perspective, you should have one cell class with an attribute "taken", or as another anwer suggests, "owner information". If you feel that this should not be part of the cell class for whatever reason, what about keeping the owner information separate in a Map<Cell,Owner> ?

Answer 3

Okay, here's another approach you can take.

 public class Cell {

     private int x;
     private int y;
     private OccupationInfo occupationInfo;

     public int posX() {
         return x;
     }

     public int posY() {
        return y;
     }

     public OccupationInfo getOccupationInfo() {
        return occupationInfo;
     }

     public boolean isFree() {
        return occupationInfo == null;
     }
  }

And then...

  public class OccupationInfo {
      private Player owningPlayer;
      // any other data you would've put in `TakenCell`
  }

This may or may not be good for your exact purposes but it's a clean and simple design.

Answer 4

I think it's good place to use Factory Pattern or Abstract Factory Pattern .

Factory pattern returns an instance of several (product hierarchy) subclasses (like FreeCell , TakenCell etc), but the calling code is unaware of the actual implementation class.
The calling code invokes the method on the interface for example FreeCell and using polymorphism the correct doSomething() method gets invoked.

Instead to use instanceof (like switching) you just might invoke the same method but each class will implement it according to local overriding. This is a very powerful and common feature in many frameworks.

Instead to write:

for (Cell cell : cells) {
Cell next = cell.futureState(...);
if(next instanceof FreeCell) {
    freeCells.add(currentCell);
}
...
}

You can type:

for (Cell cell : cells) {
Cell next = cell.futureState(...);
 cell.doSomething(); // and no matter what class is FreeCell or TakenCell 
...

}

Factory pattern returns one of the several product subclasses. You should use a factory pattern If you have a super class and a number of subclasses, and based on some data provided, you have to return the object of one of the subclasses.

Links:

Abstract Factory pattern

Factory pattern

Answer 5

You can add method to Cell interface that will tell whether the cell is free:

interface Cell {
    int posX();
    int posY();
    boolean isFree();
}

class FreeCell extends BaseCell {
    public boolean isFree() { return true; }
}

class TakenCell extends BaseCell {
    private Player owningPlayer

    public boolean isFree() { return false; }

    public Player owner() {
        return owningPlayer;
    }
}

But I don't think this is much better than using instanceof

Answer 6

Can you have two Sets and move the cells from one to the other when they are taken? For example at the beginning you would have the freeSet full of cells and the takenSet empty. As cells are taken they are moved from freeSet to takenSet. If you have an interface above TakenCell and FreeCell you could type each set with the same interface.

Alternatively...

It would be helpful to see your definition of FreeCell and TakenCell but I would think you could model them as the same object with a nullable field that becomes populated to indicate that it is Taken. You could then use two sets types to the same class.

Answer 7

Your code isn't ugly, it reads well, it clearly expresses the application logic.

A single instanceof test usually isn't something to worry about; its use is common. "Marker interfaces" are tested by instanceof . Your example is kind of a marker interface.

And instanceof is insanely fast, apparently JVM finds it worthwhile to optimize it very well.

However, a chain of instanceof tests can be a sign of problem. Add a guard to make sure the enumeration is complete.

if(o instanceof A)
    ...
else if(o instanceof B)
    ...
else if ...
...
else // huh? o is null or of unknown type
    throw new AssertionError("unexpected type: "+o); 

Answer 8

you can use Visitor Pattern , these FreeCell and TakenCell should implement

Visitable interface

interface Visitable {
    void accept(Visitor visitor);
}

interface Visitor {
    void visit(FreeCell freeCell);
    void visit(TakenCell takenCell);
}

in the implementation of Visitor's visit(FreeCell freecCell) method will be:

public void visit(FreeCell freeCell) {
    freeCells.add(freeCell);
}

in the implementation of Visitor's visit(TakenCell takenCell) method will be nothing

and both classes: FreeCell and TakenCell, in method accept(Visitor visitor) should have:

public void accept(Visitor visitor) {
    visitor.visit(this);
}

and in for loop you should have:

for (Cell cell : cells) {
Cell next = cell.futureState(...);
next.accept( someConcreteVisitor )
...
}

someConcreteVisitor is the Visitor's implementer's instance.

the class, where this for loop is, can be Visitable too.