如果你需要在车库中区分Car和Boat，那么你应该将它们存储在不同的结构中。

例如:

public class Garage {
    private List<Car> cars;
    private List<Boat> boats;
}

然后，您可以定义特定于船或特定于汽车的方法。

那为什么要多态呢?

假设Vehicle是这样的:

public abstract class Vehicle {
   protected int price;
   public getPrice() { return price; }
   public abstract int getPriceAfterYears(int years);
}

每个Vehicle都有一个价格，所以它可以放在Vehicle抽象类中。

然而，决定n年后价格的公式取决于车辆，因此留给实现类来定义它。例如:

public Car extends Vehicle {
    // car specific
    private boolean automatic;
    @Override
    public getPriceAfterYears(int years) {
        // losing 1000$ every year
        return Math.max(0, this.price - (years * 1000));  
    }
}

Boat类可能对getPriceAfterYears和特定的属性和方法有其他定义。

现在回到Garage类，你可以定义:

// car specific
public int numberOfAutomaticCars() {
    int s = 0;
    for(Car car : cars) {
        if(car.isAutomatic()) {
            s++;
        }
    }
    return s;
}
public List<Vehicle> getVehicles() {
    List<Vehicle> v = new ArrayList<>(); // init with sum
    v.addAll(cars);
    v.addAll(boats);
    return v;
}
// all vehicles method
public getAveragePriceAfterYears(int years) {
    List<Vehicle> vehicules = getVehicles();
    int s = 0;
    for(Vehicle v : vehicules) {
        // call the implementation of the actual type!
        s += v.getPriceAfterYears(years);  
    }
    return s / vehicules.size();
}

多态性的兴趣在于能够调用车辆上的getPriceAfterYears而不关心实现。

通常，下倾是设计缺陷的标志:如果需要区分车辆的实际类型，请不要将所有车辆存储在一起。

注:当然这里的设计可以很容易地改进。这只是一个例子来证明这一点。

Modeling objects you want to present in a program (in order to solve some problem) is one thing, coding is another story. In your code, I think essentially it's inappropriate to model a garage using array. Arrays shouldn't be often considered as objects, although they do appear to be, usually for the sake of self-contained-ness sort of integrity of a language and providing some familiarity, but array as a type is really just a computer-specific thing, IMHO, especially in Java, where you can't extend arrays.

我知道正确地建模一个类来表示车库并不能帮助回答“车库中的汽车”的问题;只是一个建议。

回到代码。除了一些面向对象的问题之外，一些问题将有助于创建一个场景，从而更好地理解你想要解决的问题(假设有一个问题，而不仅仅是“得到一些问题”):

谁或什么东西想了解carIsAutomatic? 给定carIsAutomatic，谁或什么将执行doSomeCarStuff?

It might be some inspector, or someone who knows only how to drive auto-transmission cars, etc., but from the garage's perspective, all it knows is it holds some vehicle, therefore (in this model) it is the responsibility of this inspector or driver to tell if it's a car or a boat; at this moment, you may want to start creating another bunch of classes to represent similar types of *actor*s in the scene. Depends on the problem to be resolved, if you really have to, you can model the garage to be a super intelligent system so it behaves like a vending machine, instead of a regular garage, that has a button says "Car" and another says "Boat", so that people can push the button to get a car or a boat as they want, which in turn makes this super intelligent garage responsible for telling what (a car or a boat) should be presented to its users; to follow this improvisation, the garage may require some bookkeeping when it accepts a vehicle, someone may have to provide the information, etc., all these responsibilities go beyond a simple Main class.

说了这么多，当然我理解编写面向对象程序的所有麻烦，以及样板，特别是当它试图解决的问题非常简单时，但面向对象确实是解决许多其他问题的可行方法。根据我的经验，有了一些提供用例的输入，人们开始设计对象如何相互交互的场景，将它们分类为类(以及Java中的接口)，然后使用像Main类这样的东西来引导世界。

这是应用访问者设计模式的好地方。

这种模式的美妙之处在于，您可以在一个超类的不同子类上调用不相关的代码，而不必到处执行奇怪的强制转换，也不必在超类中放入大量不相关的方法。

这是通过创建一个Visitor对象并允许我们的Vehicle类接受()访问者来实现的。

您还可以创建许多类型的Visitor，并使用相同的方法调用不相关的代码，只是不同的Visitor实现，这使得这种设计模式在创建干净的类时非常强大。

举个例子:

public class VisitorDemo {

    // We'll use this to mark a class visitable.
    public static interface Visitable {

        void accept(Visitor visitor);
    }

    // This is the visitor
    public static interface Visitor {

        void visit(Boat boat);

        void visit(Car car);

    }

    // Abstract
    public static abstract class Vehicle implements Visitable {

            // NO OTHER RANDOM ABSTRACT METHODS!

    }

    // Concrete
    public static class Car extends Vehicle {

        public void doCarStuff() {
            System.out.println("Doing car stuff");
        }

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

    }

    // Concrete
    public static class Boat extends Vehicle {

        public void doBoatStuff() {
            System.out.println("Doing boat stuff");
        }

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

    }

    // Concrete visitor
    public static class StuffVisitor implements Visitor {

        @Override
        public void visit(Boat boat) {
            boat.doBoatStuff();
        }

        @Override
        public void visit(Car car) {
            car.doCarStuff();
        }
    }

    public static void main(String[] args) {
        // Create our garage
        Vehicle[] garage = {
            new Boat(),
            new Car(),
            new Car(),
            new Boat(),
            new Car()
        };

        // Create our visitor
        Visitor visitor = new StuffVisitor();

        // Visit each item in our garage in turn
        for (Vehicle v : garage) {
            v.accept(visitor);
        }
    }

}

如您所见，StuffVisitor允许您在Boat或Car上调用不同的代码，这取决于调用哪个访问实现。您还可以创建Visitor的其他实现，以使用相同的.visit()模式调用不同的代码。

还要注意，使用此方法时，不使用instanceof或任何hack类检查。类之间唯一重复的代码是方法void accept(Visitor)。

例如，如果你想支持3种类型的具体子类，你也可以将该实现添加到Visitor接口中。

我真的只是汇集了其他人的想法(我不是Java的人，所以这是伪的而不是实际的)，但是，在这个人为的例子中，我将把我的汽车检查方法抽象为一个专门的类，它只知道汽车，只关心查看车库时的汽车:

abstract class Vehicle { 
    public abstract string getDescription() ;
}

class Transmission {
    public Transmission(bool isAutomatic) {
        this.isAutomatic = isAutomatic;
    }
    private bool isAutomatic;
    public bool getIsAutomatic() { return isAutomatic; }
}

class Car extends Vehicle {
    @Override
    public string getDescription() { 
        return "a car";
    }

    private Transmission transmission;

    public Transmission getTransmission() {
        return transmission;
    }
}

class Boat extends Vehicle {
    @Override
    public string getDescription() {
        return "a boat";
    }
}

public enum InspectionBoolean {
    FALSE, TRUE, UNSUPPORTED
}

public class CarInspector {
    public bool isCar(Vehicle v) {
        return (v instanceof Car);
    }
    public bool isAutomatic(Car car) {
        Transmission t = car.getTransmission();
        return t.getIsAutomatic();
    }
    public bool isAutomatic(Vehicle vehicle) {
        if (!isCar(vehicle)) throw new UnsupportedVehicleException();
        return isAutomatic((Car)vehicle);
    }
    public InspectionBoolean isAutomatic(Vehicle[] garage, int bay) {
        if (!isCar(garage[bay])) return InspectionBoolean.UNSUPPORTED;
        return isAutomatic(garage[bay]) 
             ? InspectionBoolean.TRUE
             : InspectionBoolean.FALSE;
    }
}

重点是，当你问汽车的传动装置时你已经决定只关心汽车了。所以只要问问CarInspector就行了。多亏了三状态枚举，你现在可以知道它是自动的，甚至它不是一辆车。

当然，你需要为你关心的每辆车使用不同的vehicleinspector。你已经把哪个VehicleInspector实例化的问题推到了链上。

因此，您可能想要查看接口。

抽象getTransmission到接口(例如hastrtransmission)。这样，你就可以检查车辆是否有变速器，或者写一个TransmissionInspector:

abstract class Vehicle { }

class Transmission {
    public Transmission(bool isAutomatic) {
        this.isAutomatic = isAutomatic;
    }
    private bool isAutomatic;
    public bool getIsAutomatic() { return isAutomatic; }
}

interface HasTransmission { 
    Transmission getTransmission(); 
}

class Car extends Vehicle, HasTransmission {
    private Transmission transmission;

    @Override
    public Transmission getTransmission() {
        return transmission;
    }
}

class Bus extends Vehicle, HasTransmission {
    private Transmission transmission;

    @Override
    public Transmission getTransmission() {
        return transmission;
    }
}

class Boat extends Vehicle { }

enum InspectionBoolean {
    FALSE, TRUE, UNSUPPORTED
}

class TransmissionInspector {
    public bool hasTransmission(Vehicle v) {
        return (v instanceof HasTransmission);
    }
    public bool isAutomatic(HasTransmission h) {
        Transmission t = h.getTransmission();
        return t.getIsAutomatic();
    }
    public bool isAutomatic(Vehicle v) {
        if (!hasTranmission(v)) throw new UnsupportedVehicleException();
        return isAutomatic((HasTransmission)v);
    }
    public InspectionBoolean isAutomatic(Vehicle[] garage, int bay) {
        if (!hasTranmission(garage[bay])) return InspectionBoolean.UNSUPPORTED;
        return isAutomatic(garage[bay]) 
             ? InspectionBoolean.TRUE
             : InspectionBoolean.FALSE;
    }
}

现在你说，你只关心变速器，而不考虑车辆，所以可以问变速器检查员。TransmissionInspector可以检查公共汽车和汽车，但它只能询问有关变速器的信息。

现在，您可能认为布尔值并不是您所关心的全部。在这一点上，你可能更喜欢使用泛型的Supported类型，它同时暴露了受支持的状态和值:

class Supported<T> {
    private bool supported = false;
    private T value;

    public Supported() { }
    public Supported(T value) { 
        this.isSupported = true;
        this.value = value; 
    }

    public bool isSupported() { return supported; }
    public T getValue() { 
        if (!supported) throw new NotSupportedException();
        return value;
    }
}

现在你的检查器可能被定义为:

class TransmissionInspector {
    public Supported<bool> isAutomatic(Vehicle[] garage, int bay) {
        if (!hasTranmission(garage[bay])) return new Supported<bool>();
        return new Supported<bool>(isAutomatic(garage[bay]));
    }

    public Supported<int> getGearCount(Vehicle[] garage, int bay) {
        if (!hasTranmission(garage[bay])) return new Supported<int>();
        return new Supported<int>(getGearCount(garage[bay]));
    }
}

正如我说过的，我不是一个Java人，所以上面的一些语法可能是错误的，但这些概念应该是成立的。然而，在没有测试之前，不要在任何重要的地方运行上面的代码。

你问管家:

吉夫斯，还记得我在爪哇岛的车库吗?去看看第一辆停在那里的车是不是自动挡的。

懒惰的吉夫斯说:

但是，先生，如果这是一辆既不能自动也不能非自动的车呢?

这是所有。

好吧，这还不是全部，因为现实中更多的是鸭子类型而不是静态类型。这就是为什么我说吉夫斯很懒。

你在这里的问题是在一个更基本的层面上:你以这样一种方式构建了Vehicle，车库需要了解更多关于它的对象的信息，而不是Vehicle接口所提供的信息。您应该尝试从Garage透视图来构建Vehicle类(通常从所有将使用Vehicle的东西的透视图来构建):他们需要用他们的车辆做什么样的事情?我怎样才能用我的方法实现这些呢?

例如，从你的例子:

bool carIsAutomatic = myGarage[0].auto;

你的车库想知道一辆车的发动机…原因吗?不管怎样，没有必要只是通过Car来曝光。你仍然可以在Vehicle中暴露一个未实现的isAutomatic()方法，然后在Boat中实现它为return True并返回this。Car中的auto。

如果有一个三值的EngineType enum (HAS_NO_GEARS, HAS_GEARS_AUTO_SHIFT, HAS_GEARS_MANUAL_SHIFT)会更好，这会让你的代码清晰而准确地推断出通用车辆的实际特征。(无论如何，你需要区分摩托车。)