Java 基础对象多类型变量

Question

我确信这在 Java 以 OOP 为中心的情况下非常普遍。在java中有没有办法制作一个接受所有继承子类型的基类型变量？就像我有；

class Mammal {...}
class Dog extends Mammal {...}
class Cat extends Mammal {...}

class ABC {
    private Mammal x;

    ABC() {
        this.x = new Dog();
        -or-
        this.x = new Cat();
    }
}

我也需要该变量能够接受任何扩展版本，但不是特定的一种扩展类型。

有些方法我知道，但不想使用。我可以为每个子类型创建一个属性，然后只使用一个属性。制作一个数组并将其推入其中。

任何其他想法或获得“基类”类型变量的方法？

---

好的，因为我知道在 Java 中使用多态鸭子类型并不是一个好主意，但是因为我认为我无法避免它。是动态使用子类方法重新分配变量的强制转换版本的唯一方法，即，我得到一个错误；

Mammal x;
x = new Dog();
System.out.println(x.getClass());
x.breath();
if (x instanceof Dog) {
  x.bark();
} else if (x instanceof Cat) {
  x.meow();
}

没有找到说符号，但是这有效；

Mammal x;
x = new Dog();
System.out.println(x.getClass());
x.breath();
if (x instanceof Dog) {
  Dog d = (Dog) x;
  d.bark();
} else if (x instanceof Cat) {
  Cat c = (Cat) x;
  c.meow();
}

最后一个是唯一的方法吗？

Answer 1

如果您有以下情况：

class Mammal {...}
class Dog extends Mammal {...}
class Cat extends Mammal {...}

那么Dog 是Mammal 的子类型。 Cat 也是Mammal 的子类型。这种类型多态性实际上允许您执行以下操作：

Mammal x;
x = new Dog(); // fine!
x = new Cat(); // also fine!

如果事实上以后有以下内容：

class Platypus extends Mammal {...} // yes it's true!

那么你也可以这样做：

x = new Platypus(); // fine!

这种多态子类型关系是面向对象编程的基本原则之一。

另见

• Java Tutorials/Object-Oriented Programming Concepts
• Wikipedia/Polymorphism in object-oriented programming

  Subtype polymorphism，在面向对象编程的上下文中几乎普遍称为多态性，是一种类型 A 出现并像另一种类型 一样使用的能力B

---

开启instanceof 类型比较运算符

假设我们有以下内容：

class Mammal { void lactate(); }
class Dog extends Mammal { void bark(); }
class Cat extends Mammal { void meow(); }

然后你可以使用instanceof类型比较运算符（§15.20.2）来做这样的事情：

Mammal x = ...;

if (x instanceof Dog) {
   Dog d = (Dog) x;
   d.bark();
} else if (x instanceof Cat) {
   Cat c = (Cat) x;
   c.meow();
}
if (x != null) {
   x.lactate();
}

没有if-else也有办法做到这一点；这只是一个简单的例子。

请注意，通过适当的设计，您也许可以避免其中一些类型的子类型区分逻辑。例如，如果Mammal 有makeSomeNoise() 方法，您可以简单地调用x.makeSomeNoise()。

相关问题

• When should I use the Visitor Design Pattern? - 有时用于模拟双重调度

---

反思

如果您必须处理编译时未知的新类型，那么您可以求助于反射。请注意，对于一般应用程序，几乎总是有比反射更好的替代方案。

另见

• Java Technical Articles/Advanced Language Topics/Reflection
• Effective Java 第 2 版，第 53 条：首选接口而不是反射