Java：为什么我的List包含不同的类型？ （过滤列表）

Question

The whole time I thought, if I am using a List like List<Thing> things = new ArrayList<>() all items in this list are of Type Thing . Yesterday i was taught the other way.

I've created the following stuff and wonder why it is like it is.

An Interface Thing

public interface Thing {
  String getType();

  String getName();
}

A class ObjectA

public class ObjectA implements Thing {
  private static final String TYPE = "Object A";
  private String name;

  public ObjectA(String name) {
    this.name = name;
  }

  @Override
  public String toString() {
    final StringBuffer sb = new StringBuffer("ObjectA{");
    sb.append("name='").append(name).append('\'');
    sb.append('}');
    return sb.toString();
  }

  @Override
  public String getType() {
    return TYPE;
  }

  @Override
  public String getName() {
    return name;
  }

  // equals and hashCode + getter and setter
}

A class ObjectB

public class ObjectB implements Thing {
  private static final String TYPE = "Object B";
  private String name;
  private int value1;
  private String value2;
  private boolean value3;

  public ObjectB(String name, int value1, String value2, boolean value3) {
    this.name = name;
    this.value1 = value1;
    this.value2 = value2;
    this.value3 = value3;
  }

  @Override
  public String getType() {
    return TYPE;
  }

  @Override
  public String getName() {
    return name;
  }

  @Override
  public String toString() {
    final StringBuffer sb = new StringBuffer("ObjectB{");
    sb.append("name='").append(name).append('\'');
    sb.append(", value1=").append(value1);
    sb.append(", value2='").append(value2).append('\'');
    sb.append(", value3=").append(value3);
    sb.append('}');
    return sb.toString();
  }

  // equals and hashCode + getter and setter
}

The main method

  public static void main(String[] args) {
    final List<Thing> things = new ArrayList<>();
    final ObjectA objA = new ObjectA("Thing 1");
    final ObjectB objB = new ObjectB("Thing 2", 123, "extra", true);

    things.add(objA);
    things.add(objB);

    // The List doesn't contain Thing entities, it contains ObjectA and ObjectB entities
    System.out.println(things);

    for(final Thing thing : things) {
      if (thing instanceof ObjectA) {
        System.out.println("Found Object A: " + thing);
        final ObjectA object = (ObjectA) thing;
      }
      if (thing instanceof ObjectB) {
        System.out.println("Found Object B: " + thing);
      }
    }
  }

The output of this method is:

[ObjectA{name='Thing 1'}, ObjectB{name='Thing 2', value1=123, value2='extra', value3=true}]

So i assume i've ObjectA entities and ObjectB entities in my List<Thing> .

Question: Can someone provide a link (or some keywords which can be used for searching), which explain this behavior, or can explain it to me?

additional Question: I've started to filter this List<Thing> with instanceof but i have read instanceof and casting are bad practice (eg no good model design). Is the are "good" way to filter this List for all Types of ObjectA to perform only on these objects some operations?

Answer 1

You should avoid instanceof check in your additional question example. When you work with List items, it should be sufficient to have interface methods available. If you need to do something with only ObjectA or ObjectB, I suggest to use another List with only ObjectA or ObjectB. For example you can define different methods to do Thing specific job and ObjectB specific job:

public void processThings(List<Thing> things) {

        for(final Thing thing : things) {

            // we work only with methods that provided by interface Thing
            System.out.println(thing.getType());
            System.out.println(thing.getName());

        }
    }

public void processObjectsB(List<ObjectB> objectsB) {

        // here we do some specific things with only B objects, 
        // assuming class ObjectB has an additional method doSomeSpecificB()
        for(final ObjectB objectB : objectsB) {

            objectB.doSomeSpecificB();

        }
    }

Answer 2

I have a garden that contains potatoes, carrots and broccoli. I have a very strict rule - I won't plant anything in the garden that I can't eat. So no poison ivy here!

So this is a Garden<Edible> - everything I plant in the garden has to be edible.

Now class Potato implements Edible means that every potato is edible. But it also means that I can plant a potato in my garden. Likewise, class Carrot implements Edible - all carrots are edible, and I'm allowed to plant carrots.

It's a dark night, and I'm hungry. I go out to my garden and put my hand on something in the garden. I can't see what it is, but I know that everything in my garden is edible. So I pull it out of the garden, and take it inside to cook and eat. It doesn't matter what I've grabbed - I know it will be something I can eat.

Because this is a Garden<Edible> . It may or may not contain Potato objects. It may or may not contain Broccoli objects. It does not contain PoisonIvy objects.

Now, translate that all to your example. You have class ObjectA implements Thing - which means that every ObjectA is a Thing . You have class ObjectB implements Thing - which means that every ObjectB is a Thing . And you have a List<Thing> - a List that can contain ObjectA objects, ObjectB objects, and any other object of any class that implements Thing . What you can't put in it is an object of any class that doesn't implement Thing .

Answer 3

Can someone provide a link (or some keywords which can be used for searching), which explain this behavior, or can explain it to me?

This behaviour is called "polymorphism". Basically, since ObjectA and ObjectB implements Thing , instances of ObjectA and ObjectB can be used like a Thing object. In your code, you added them to a list that can contain Thing objects.

Note how even if those objects are now of (compile time) type Thing , at runtime they still know what they are. When you call toString on them, the respective overridden toString methods in ObjectA and ObjectB will be called. It is as if the Thing "morphs" into ObjectA or ObjectB .

Is the are "good" way to filter this List for all Types of ObjectA to perform only on these objects some operations?

The reason why people say this is bad practice is because if you want to do different things depending whether the object is ObjectA or ObjectB , why did you make them implement Thing and make a list of Thing to store them? You could have just used a List<Object> . The real advantage of using List<Thing> is that you avoid knowing what actual objects are in there when you are working with the list. All you know is that the things inside the list implement Thing and you can call methods declared in Thing .

So if you need to filter the list to separate the two types, you could have just created two lists to store them in the first place. One for ObjectA and one for ObjectB . Obviously, this is not always possible, especially if the list comes from somewhere else (like a external library). In that case, your current code is fine.

Answer 4

things is a List<Thing> . That means that at compile time, Java will ensure that any object that you write to things is a Thing . As ObjectA and ObjectB both implement Thing the actual implementation of any member of things can be ObjectA or ObjectB . This is by design and that feature is called polymorphism : object of different classes share a common interface and can be accessed thrrough that interface independently of their actual type. For example you could use:

for(final Thing thing : things) {
    System.stdout.println("Found a " + thing.getType() + " named " + thing.getName());
}

Using instanceof and casting is not necessarily bad practice and can have correct use case. But it is often a hint that the hierachy of classes and interfaces has not been properly designed. Ideally, if you have to process a Thing , you should not wonder about its actual class: you have a Thing , and using Thing methods should be enough.

In that sense, instanceof is at the same level as reflection is: it is a low level tool that allows to see what is hidden under the hood. And any time you use it, you should ask you whether polymorphism could not be enough.