问题标签 [marker-interfaces]

SelfComparable Interface在练习反思时，我在Collections课堂上了解到

这个接口有什么用？

我有一个应用程序使用来自公共基类的多种类型的派生类，并且一些派生类使用泛型。应用程序经常需要遍历派生类的集合并识别特定的类类型以进行特殊处理。

问题是如何在不知道类型的情况下以简洁优雅的方式测试基类的特定泛型衍生物（因为它经常在项目中完成）？

'is' 运算符不适用于此：

为了解决这个问题，我正在考虑使用空标记接口来识别集合中的特殊类。这似乎是最干净的解决方案。

几点注意事项：

• 这是一个封闭的项目，不会是一个商业分布式库。
• 由标记接口标记的类被标记为永久唯一类型，并且该类型的所有派生类都将正确继承标记。

下面的一个例子：

有没有人对如何解决这个问题有更好的想法？

谢谢。

任何人都可以解释一下 JVM 如何在内部处理标记接口，例如：

从技术上讲，我知道为什么类需要实现可序列化。原因是 ObjectOutputStream 的 writeObject 方法在写入对象状态之前在内部检查“可序列化的实例”。

但我的问题是，这有什么需要？writeObject 方法可以简单地写入对象状态，无论对象（需要写入其状态）是否实现可序列化？

根据wiki，一个类实现此接口以指示其非瞬态数据成员可以写入 ObjectOutputStream。但另一个问题是为什么类需要实现可序列化只是为了确定字段是否是瞬态的。即使是没有实现可序列化的类也应该被序列化（标记为瞬态的字段除外）。

将对象标记为可序列化（带有接口）并不会神奇地使该对象可序列化，它一直是可序列化的，只是现在您表达了系统可以自己找到的东西，所以我认为没有真正好的理由序列化就是现在的样子。

为什么类需要实现可序列化标记接口来序列化类？

在 Java 中，我们使用 的writeObject(Object obj)方法ObjectOutputStream来序列化一个Object.

但是由于该方法只接受实现java.io.Serializable接口的对象（或者它会抛出NotSerializableException），为什么它仍然使用Object参数而不是Serializable，比如writeObject(Serializable o)？

有没有设计考虑？

我一直在考虑这个但不能马上放弃它，为什么我们甚至会在我们的类中实现标记接口，即使它们不包含任何方法。请告诉我

声明的方法签名似乎是相等的。那么引入 Set 接口而不是直接实现 Collection 的目的是什么？还是这里只是一个标记界面？

我想知道，创建标记虚拟类（内部没有成员）是否仅用于通用签名是一个好主意。

例如，考虑下面的接口签名：

实现上述接口的示例具体类可以是：

在上面的具体类定义中，CreationContext类（它实现了标记接口IContext）是一个没有属性的虚拟类，但仅用于将其与同一 Customer 类的其他验证器区分开来，但用于不同的其他上下文。

这种方法是个好主意吗？有没有比使用虚拟无成员空类更好的设计替代方案？

上述设计的目的是允许为同一个实体创建多个验证器具体类，但针对不同的上下文，并将其与依赖注入容器一起使用。

以下代码显示了此类验证器在各种上下文中的用法：

非常感谢您的时间和帮助！

我对java中的标记接口感到困惑。

当我们在标记接口中没有方法时，谁能告诉我，然后从哪里调用它。我们是否也必须明确地实现这一点。

我想检索在对象的参数化标记接口上找到的泛型类型的实际类。这甚至可能吗？

标记界面：

我想要的方法：

对于那些想知道我为什么要这样做的人：对于一些重型 jpa 实体，我有多个 dto jpa 实体。我想创建一个通用服务，为提供的 dto 检索正确的完整实体 spring 数据 jpa 存储库。dto 有一个标记接口，它将完整实体类指定为参数化的泛型类型。