java - 抽象基类还是类？

Question

对于我的学期项目，我和我的团队应该制作一个包含游戏开发框架并演示 OOP 概念的 .jar 文件(库，不可运行)。它应该是一个框架，另一个团队应该使用我们的框架，反之亦然。所以我想知道我们应该如何开始。我们想到了几种方法:
1. 从普通类开始

public class Enemy {
    public Enemy(int x, int y, int health, int attack, ...) {
        ...
    }
    ...
}
public class UserDefinedClass extends Enemy {
    ...
}

2。从一个抽象类开始，用户定义的敌人必须继承抽象成员

public abstract class Enemy {
    public Enemy(int x, int y, int health, int attack, ...) {
        ...
    }
    public abstract void draw();
    public abstract void destroy();
    ...
}
public class UserDefinedClass extends Enemy {
    ...
    public void draw() {
        ...
    }
    public void destroy() {
        ...
    }
}

3。创建一个ALL继承自的 super ABC(抽象基类)

public abstract class VectorEntity {
    ...
}
public abstract class Enemy extends VectorEntity {
    ...
}
public class Player extends VectorEntity {
    ...
}
public class UserDefinedClass extends Enemy {
    ...
}

我应该使用哪个？或者有更好的方法吗？

Answer 1

好吧，如果不深入了解您在做什么，就很难肯定地说，即使这样也是相当主观的。但是，有一些事情可以告诉您需要考虑的事情。

1. 他们是要实际实例化一个 Enemy，还是所有的敌人真的都需要是派生类型？如果您实际上不打算实例化 Enemies 而不是派生类型，那么它应该是接口(interface)或抽象类。

2. 如果您希望在基类中提供实际行为，那么显然它需要是类而不是接口(interface)。

3. API 需要的方法，但对您提供任何实现没有任何意义的方法应该是抽象的。

4. 在基类中实现它们很有意义的方法应该在基类中实现。如果覆盖它们没有什么意义，那么将它们设为最终的。

5. 让类共享一个公共(public)基类只有在它们真正共享行为或者您需要能够在代码中的某处对它们一视同仁时才有意义。如果它们不是真的那么相似，那么它们可能不应该共享一个基类。例如，如果 Enemy 和 Player 都应该是可显示的，那么有一个共同的基类来处理它们的显示功能可能是有意义的。但是如果 Enemy 是可显示的东西，而 Player 是一个更抽象的概念——比如游戏的 Controller ——并且不可显示，那么它们共享一个基类可能就没有意义了。一般来说，在构建类时更喜欢组合而不是继承，所以如果有问题的类不会真正共享行为并且与公共(public)基类没有真正的“is-a”关系，那么他们不应该共享一个共同的基类。

6. 希望基类只共享方法，而不共享数据。换句话说，在继承树中，最好只有叶子是可实例化的。有很多类似 equals() 的东西，当你有包含实际数据的基类时，它们就会崩溃。这并不是说您不能这样做 - 人们一直都在这样做 - 但它可能会导致问题，如果不需要，最好避免这样做。

7. 更喜欢覆盖抽象方法。否则，在派生类中，您可能会面临不调用基类的方法或完全改变该方法的作用的风险。

我确信我可以想出更多，但如果不真正熟悉您的项目，它肯定会相当通用。在你给出的 3 个选项中，我可能会选择 2。3 看起来你可能会为不相关的类创建一个基类，而 1 会导致 Enemy 被实例化，你可能不需要并且肯定会做到这一点，这样您的继承层次结构中的叶子就可以实例化了。您可能最终仍会在基类中使用 2 中的数据，但您更有可能只重写抽象方法，并且在派生类中更改行为的问题会更少。