问题标签 [sealed-class]

我无法理解如何/何时使用 Kotlin 在 Android 中使用密封类。我已经阅读了文档，但我仍然对它的结构以及如何使用它感到困惑。如果有人可以帮助我理解这一点，那将有很大帮助。

我有一个像这样的密封类

我将密封类与 LiveData 一起使用，它可以工作

但是当我将 MutableLiveData 更改为 MutableStateFlow 时，我收到这样的警告

那么，如何在 MutableStateFlow 中使用密封类？

我有一个密封类声明如下：

我有一个将 SealedClass 键映射到字符串值的映射，并且我想在访问映射中的 SealedClass.Pizza 键时检索特定字符串，但是当我尝试使用时访问 SealedClass.Pizza 条目的结果返回 null我在代码的不同段中构造的 SealedClass.Pizza 键。

生成的 SealedClass.Pizza 对象似乎具有不同的哈希值，这可能可以解释为什么会出现这种情况。打印它们会导致

SealedClass$Pizza@4cf4ae53和SealedClass$Pizza@21773412

我的印象是对象在一个类的所有实例中都是相同的，所以我不知道为什么它们有不同的哈希值，但无论如何，我希望能够使用这两个SealedClass.Pizza对象来访问相同的字符串。我该怎么做？

我有以下课程：

当我尝试转换通用时ArrayList：

到AudioItem

我得到：

无法构造实例AudioItem（没有创建者，如默认构造函数，不存在）：抽象类型要么需要映射到具体类型，要么具有自定义反序列化器，要么包含额外的类型信息

在设计一个干净的架构时，处理应用程序异常的最佳方法是什么。

1 - 使用带有内部类集的密封类

缺点：

• 这些内部类的自定义内部实现都将在同一个类文件中

优点：

• 您可以从 when 子句中受益，以耗尽所有错误类型

2 - 使用扩展异常的异常类

缺点：

• 如果有自定义实现，调用代码就变成了一些样板代码。
• 不是详尽的方法。

优点：

• 您可以为每个自定义异常或错误拥有单独的类文件。
• 灵活地通过创建类来实现几个自定义异常。

1. 创建一个 BaseUIState 类型的密封类来处理大部分状态
2. 但是当我需要额外的状态时，我会让另一个密封类继承该类并添加一个新状态
3. 所以我不得不在 baseviewModel 中发送一个从 BaseUIState 扩展的通用状态
4. 项目清单

在 BaseViewmodel 类型的 BaseUIState 中使用泛型并在 mvi 中为其分配初始值时会出错

随着 Kotlin1.5的推出，sealed interface. 即使我知道类和接口之间的区别，我也不清楚使用sealed interfaceover的最佳实践和好处是什么sealed class

interface即使是一个简单的案例，我现在应该一直使用吗？还是会因情况而异？

谢谢

Obs：没有找到类似的问题，只有关于sealed classes

今天我将我的 java 版本从 16 更新到 17，我发现sealedclass 是其中的一个新特性。我认为可以这样声明——

但是java中密封类有什么用呢？

我也知道这是 jdk-15 中的预览功能

我正在使用 RXJava 改造来调用我的 API，我正在尝试将我的调用结果映射到密封类成功和失败部分，

我做了映射部分，但我总是收到这个错误java.lang.RuntimeException: Failed to invoke private Result() with no args

这是我的代码：

改造界面

结果密封类

调用和映射

有人可以帮忙吗？为什么我会收到此错误？

我正在尝试使用 Arrow Either结果而不是 try-catch，但在兔子洞中走得太深了。

我一直在尝试将其Either<Problem,Value>用作我的功能返回类型，Problem就像

用例的样子

但是，确实存在三种类型的问题，我不想一直用尽所有选择。

例如，我想要类似的东西

我希望能够有一些代码，比如

但是 Kotlin 抱怨NotHandled,DataKeyDiabled并且SubscriberNotFound不是DataProblem

在某些情况下，我想返回 aKeyProblem以便我可以从 中删除NotEncrypted案例when，而在某些情况下，我只想返回 aProblem这样唯一的案例是NotHandled.

我不知道如何在 Kotlin 中表达这一点。我怀疑不可能在 Kotlin 中表达这一点，所以如果有人告诉我这是不可能的，那就是一个解决方案。

我认为用 Arrow Either 代替 try-catch 是一个错误的决定。如果是这样，请有人告诉我。

我想坚持函数式反应式编程范式，其中 try-catch 不起作用，但使用 Kotlin 协程它确实可以工作。

在我看来，密封的东西的问题是使用时when只能有一层继承，不能再多了？

也许我只是以错误的方式看待整个问题...帮助...请...