java中标记接口的意义是什么？为什么没有它们我们就不能继续下去？

Question

我已经阅读了有关标记接口的内容，并且对如何在代码中使用它们有了一些了解，但我不明白为什么我们需要它们以及引入这个概念的原因是什么。

我在互联网上搜索，所有答案都是“它们向 JVM 提供一些基本信息，以便 JVM 可以执行一些有用的操作”，但问题是为什么 JVM 需要知道这一点以及 JVM 可能执行哪些操作必须执行？为什么我不能只克隆对象而不从 Clonable 扩展类？为什么我不能序列化类对象而不从 Serialized 扩展它？

标记界面没有多大意义，在我看来显然不是一个好的设计。没有任何方法的接口？？？重点是什么？

现在显然这里使用注释而不是标记接口，但问题仍然是为什么 JVM 需要知道？

Answer 1

您清楚地了解标记接口的作用。你自己也这么说啊！那么为什么我们还需要它们呢？从某种意义上说，我们不需要它们。任何可以用标记接口表达的东西都可以用注释来表达。毫无疑问，注释是解决问题的一种更简洁的方法。我们（仍然）拥有标记接口的根本原因是历史：Java 注释是在 Java 5.0 中添加到 Java 语言中的。在此之前，标记接口是可用的最佳解决方案。从类中删除标记接口会破坏二进制兼容性。有少量 Java SE 标记接口早于 Java 5.0，并广泛用于用户代码中。我想到的两个是Serializable和Cloneable。无论我们喜欢与否，Java 都有标记接口，而且这一点不太可能改变。标记界面没有多大意义，在我看来显然不是一个好的设计。嗯，是。从2019年的角度来看，确实如此。从 1997 年的角度来看，当时 Java 还很新，C# 也已经面世 5 年了，唯一具有注释之类的主流语言是 LISP 版本。现在我非常确定，早在 Java 1.0 时代，Java 类库的设计者就意识到标记接口是一个有缺陷的想法。但他们别无选择。它是使用标记接口，或者将一些漂亮的 Java 基础 API 的设计和实现推迟 5 年或更长时间。在企业计算领域，您需要做出妥协才能完成工作。

Answer 2

您不需要实现 Serialized 来进行序列化，也不需要实现 Cloneable 来进行克隆。这些接口的要点在于，Java 内置了用于克隆和序列化的机制，如果您希望使用这些内置机制，则只需实现这些接口即可。因此，只需实现 Serialized，您就可以自动将该类与 ObjectInputStream 和 ObjectOutputStream 一起使用，而无需任何额外的代码。另一方面，我发现可克隆几乎毫无用处。通常，您只需实现 Cloneable 并覆盖Object.clone并将其公开，然后您就可以立即进行克隆。但据说它被破坏了，你最好只编写自己的克隆逻辑，就像使用复制构造函数一样。

Answer 3

我可以回答你的部分问题 - java中标记接口的意义是什么？通过引入注解，Java 为我们提供了一种替代方法来实现与标记接口相同的结果。此外，与标记接口一样，我们可以将注释应用于任何类，并且可以将它们用作执行某些操作的指示符。那么关键的区别是什么？与注释不同，接口允许我们利用多态性。因此，我们可以向标记接口添加额外的限制。例如，让我们添加一个限制，即只能从数据库中删除 Shape 类型：public interface Shape {    double getArea();    double getCircumference();}在这种情况下，我们的标记界面（我们称之为 DeletableShape）将如下所示：public interface DeletableShape extends Shape {}然后我们的类将实现标记接口：public class Rectangle implements DeletableShape {    // implementation details}因此，所有DeletableShape 实现也是 Shape 实现。显然，我们不能使用注释来做到这一点。然而，每个设计决策都需要权衡，多态性可以用作针对标记接口的反驳。在我们的示例中，每个扩展 Rectangle 的类都会自动实现 DeletableShape。这可能无法提供您想要的确切答案。但可以部分帮助你。

Answer 4

任何类都可以实现它而无需添加任何额外的方法/字段/开销您只需标记类即可使用/序列化即使在 Java 5.0 引入注释之后，仍然还有@Configuration标记注释@Configuration注解用于基于Spring注解的配置。@Configuration 是一个标记注释，它指示一个类声明一个或多个 @Bean 方法，并且可以由 Spring 容器处理以在运行时生成 bean 定义和这些 bean 的服务请求