问题标签 [java-sealed-type]

我真的不明白为什么non-sealed在 JEP 360/Java 15 中有一个关键字。对我来说，密封类的扩展应该只是 final 或密封类本身。

提供“非密封”关键字将邀请开发人员进行黑客攻击。为什么我们允许将密封类扩展到非密封类？

我有一个简单的密封类，MyShape：

还有一个简单的子类MyCircle：

当两个类都在同一个包中时，一切都可以编译和工作。如果我将 MyCircle 移动到子包中，则构建会中断：java: class is not allowed to extend sealed class: org.example.MyShape。

我对JDK 15 文档的理解是这应该有效。我错过了一步吗？

如果您想进行实验，我已经创建了一个 GitHub 存储库。

我有以下密封接口（Java 15）：

该接口由 2 个类实现：

谁能告诉我和之间的final区别non-sealed？final阻止我创建其他子类，但non-sealed适用于什么行为Duck？

密封类和密封接口是 Java 15 中的一个预览功能，Java 16中有第二个预览，现在建议在 Java 17 中交付。

他们提供了经典示例，例如Shape-> Circle、Rectangle等。

我了解密封类：switch提供的语句示例对我来说很有意义。但是，密封接口对我来说是个谜。任何实现接口的类都被迫为它们提供定义。接口不会损害实现的完整性，因为接口本身是无状态的。我是否想将实现限制为几个选定的类都没关系。

你能告诉我 Java 15+ 中密封接口的正确用例吗？

以下是合法的（即我可以编译它）并在启用预览功能的 Java 15 中工作（在 eclipse 2020-09 中）

Quantity.java但是，日食在抱怨... permits QuantityImpl。当悬停在QuantityImpl一个可以阅读：

即使它编译，这是一个有效的投诉还是 eclipse 中的错误？

我正在使用 java 15 中的预览密封类，我想知道为什么关键字sealedandnon-sealed仅适用于类和接口，而不适用于方法（就像其他修饰符一样）。我想具体决定哪些方法可以被允许的子类覆盖可能很有用。

一个例子：我有一个类Unit，它有两个子类Metric和Imperial，它们最终都实现了一个基本功能，在这里kind()。

这行得通。但是，现在我不想kind()在所有子类中实现，而是提供一个对所有子类都是最终的实现，除了允许覆盖的子类。在我看来，这看起来像这样：

有什么方法可以通过新功能实现这一目标，还是我缺少其他方法？

我在 Eclipse 2020-09 和 2020-12 中有这两个课程：

A级

B类

但是，eclipse 编译器在 B 类中给了我一个编译器错误：

扩展密封类 Serializable 的类型 B 应该是 Serializable 的允许子类型

这似乎很奇怪，Serializable甚至不是密封类。我在JEP-360中一无所获。删除“implements Serializable”可以解决该错误。

这是 Eclipse 编译器中的错误吗？

正如我们所知，Java 16 带来了诸如记录、密封接口和类以及模式匹配等新特性。

今天我想在我的培训项目中使用它们。但是，我遇到了一个问题，也许我不明白一些事情。

因此，在代表我的 Intellij Idea 项目的给定代码中，情况看起来像：我有包：客户端和订单客户端类是具有三个实现的密封接口：Regular、Vip 和 SuperVip：

Order 类是一个简单的聚合，从 DDD 知道：但是 switch 语句有一个问题：

其他类：

我得到“（预期表达）”我哪里出错了？（启用了实验功能，我已经安装了Java 16 open jdk）

今天我为java 16预览创建了一个小测试项目。我创建了一个密封接口和一个最终实现。

我想知道是否可以模拟密封接口，以便我可以测试使用密封接口的实现。

然而，这一切都相当于创建了一个 java.lang.IncompatibleClassChangeError，因为无法实现密封类。

有没有办法模拟一个密封的接口？

编程时，有很多指标表明耦合不好。一个类应该尽可能少地了解其他类。所以它是模块化的，可以很容易地更换。

现在，随着密封类的引入，抽象超类知道了它的子类。据我了解，子类通常与其密封接口位于同一个包（甚至同一个文件）中。所以应该不存在包之间循环依赖的问题。

所以我想我要问的是：密封接口及其子类是否应该被视为一个单元，而不是相互依赖的模块化部分？

子类在包外的示例：

触发快乐的近距离投票者：密封接口的实现者不能存在于接口模块之外，因此答案非常简单。完全不是基于意见的。这是您可能感兴趣的 Brian Goetz 的评论：Sealed classes for classes in different packages

虽然我已经得到了答案，所以我真的不在乎是否没有其他人可以回答。祝你今天过得愉快！