如果对基类型进行操作，则只能访问它的公共方法和字段。

如果你想访问扩展类型，但有一个基类型的字段存储它(在你的情况下)，你首先必须强制转换它，然后你可以访问它:

Car car = (Car)myGarage[0];
car.doSomeCarStuff();

或更短，没有温度字段:

((Car)myGarage[0]).doSomeCarStuff();

由于您使用的是Vehicle对象，所以只能从它们的基类调用方法，而不能强制转换。因此，对于车库来说，最好区分不同数组(或者更好的列表)中的对象——数组通常不是一个好主意，因为它在处理方面远不如基于collection的类灵活。

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

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

这是通过创建一个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接口中。

You defined that your garage will store vehicles, so you do not care what type of vehicles you have. The vehicles have common features like engine, wheel, behavior like moving. The actual representation of these features might be different, but at abstract layer are the same. You used abstract class which means that some attributes, behaviors are exactly the same by both vehicle. If you want to express that your vehicles have common abstract features then use interface like moving might mean different by car and boat. Both can get from point A to point B, but in a different way (on wheel or on water - so the implementation will be different) So you have vehicles in the garage which behave the same way and you do not car about the specific features of them.

回答评论:

接口是指描述如何与外部世界通信的契约。在合同中，你定义了你的车辆可以移动，可以操纵，但你没有描述它实际是如何工作的，它是在实现中描述的。通过抽象类，你可能有共享某些实现的函数，但你也有不知道如何实现的函数。

一个使用抽象类的例子:

    abstract class Vehicle {

    protected abstract void identifyWhereIAm();
    protected abstract void startEngine();
    protected abstract void driveUntilIArriveHome();
    protected abstract void stopEngine();

    public void navigateToHome() {
        identifyWhereIAm();
        startEngine();
        driveUntilIArriveHome();
        stopEngine();
    } 
}

每辆车都将使用相同的步骤，但步骤的实现将因车辆类型而异。汽车可能会使用GPS，船只可能会使用声纳来确定它的位置。

如果对基类型进行操作，则只能访问它的公共方法和字段。

如果你想访问扩展类型，但有一个基类型的字段存储它(在你的情况下)，你首先必须强制转换它，然后你可以访问它:

Car car = (Car)myGarage[0];
car.doSomeCarStuff();

或更短，没有温度字段:

((Car)myGarage[0]).doSomeCarStuff();

由于您使用的是Vehicle对象，所以只能从它们的基类调用方法，而不能强制转换。因此，对于车库来说，最好区分不同数组(或者更好的列表)中的对象——数组通常不是一个好主意，因为它在处理方面远不如基于collection的类灵活。

如果你使用Java，可以使用反射来检查一个函数是否可用并执行它

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类这样的东西来引导世界。