Java 设计模式：回调作为方法参数

我想知道在方法参数中为操作定义回调是否比在对象中定义回调和通过setter设置回调更糟糕，这与设计模式有关

我不确定是否存在关于回调创建的设计模式

例如，假设有一个类A，我想执行一个带有回调的methodM

public class A {
    public interface Callback {
        void onEvent();
    }
    public static methodM(...) {
        // ...
    }
}

我可以这样做吗：

public static void methodM(Callback c) {
    c.onEvent();
}
// ...
A.method(this); // The class that calls the method is the callback!

而不是：

public static void setCallback(Callback callback) {
    this.callback = callback;
}
public static void methodM() {
    this.callback.onEvent();
}
// ...
A.setCallback(this); // The class that calls the method is the callback!
A.method(); 

请注意，该方法是静态的，这只是为了便于理解场景

那么，我可以使用第一种方法作为有效的设计吗

使用第一种方案的原因是为了避免内存泄漏，从而简化对多次执行的简单回调的定义，因为我必须使用列表、观察者等来控制回调列表。

我认为没有“回调模式”，它太通用了

然而，许多设计模式使用回调，比如或

这将取决于您的项目的全球架构

那段代码

public static void methodM(Callback c) {
    c.onEvent();
}
// ...
A.method(this); // The class that calls the method is the callback!

---

不要打扰我，如果像这样呈现也不是禁止的，我不认为这不是模式的问题，但有一些原则建议将回调存储在类字段中

• 单一责任原则：不要告诉

  A

  他必须做什么
• 得墨忒尔定律：任何人都不应知道

  A

  必须做什么工作
• 打开-关闭原则：在其他情况下，您可能希望有朝一日调用回调

---

还有其他一些原则，但我认为它们是最重要的。

这些原则在很大程度上取决于类和方法的意图。没有一种模式。我知道，它太通用了，但我担心第一种方法太糟糕/难看，无法使用。由于我的回调是一个非常简单的操作，我真的不想在没有任何需要的情况下控制回调列表或类似的东西。