为什么属性更改侦听器而不是可观察
2022-09-03 04:26:23
在我发现可观察性（使用观察者设计模式）之前，我在类设计方面遇到了问题，因此使用它创建了一个小应用程序，解决了我的问题。我很高兴也很自豪，因为我用了一个好的原则来解决问题。
现在我即将开始我的主要应用程序，刚刚阅读了这个
为什么海报建议不要使用可观察性，而是被告知使用属性转换器？使用可观察性是否存在任何问题？
问候
答案 1
观察者和侦听器模式非常相似。但观察者有一个弱点：所有可观察量都是一样的。您必须实现基于的逻辑，并将对象转换为具体类型到方法。instanceofObservable.update()
听众是不同的。有很多侦听器类型。例如鼠标监听器、键盘监听器等。每个都有几个回调方法（即 等）。因此，您永远不必将应该回答“是我的事件”问题的逻辑实现到事件处理程序中。keyPressed()keyReleased()
我认为这就是为什么听众模型更可取的原因。
答案 2
DejanLekic和其他人现在可能已经意识到，这不是一个.这就是整个问题！ObservableinterfaceJava.util.Observable
的用户必须从中继承，而没有别的。Observable
考虑 或 。Java.RMIListener events
推荐
-
为什么 Scanner 实现 Iterator<String>？为什么首先要实施？ScannerIterator结论 我只是想知道为什么 方法，该方法会引发 .但是是一个类，而是一个类。 这不是一个糟糕的设计实践吗？
-
DTO conveter pattern in Spring Boot 主要问题是如何在不违反 ，所以它只能转换，不能知道服务或存储库。 转换器示例： 在 conveter 类中使用存储库好吗？或者我应该创建另一个服务/组件，负责从DTO创建实体（如UserFactory）？
-
-
方法数组：适配器模式？ 问题描述：我希望能够将方法列表传递给仅在一个类中定义了方法的其他类。如果这些方法（其中一些具有输入参数和非 void 返回类型）在一个类中定义，我希望能够将其中一些方法的列表（可
-
如果我在实现工厂模式时使用抽象类而不是接口。它仍然是工厂模式吗？ 例如： 如果我在抽象类 Shape 上更改接口形状，请创建具体类来扩展 Shape，并使 Shape 工厂返回 Shape 抽象类类型化对象。它仍然是工厂模式吗？
