设计模式:作为方法参数的回调



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

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

例如,假设有一些类A,我想执行一个带有回调的方法M。

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要做什么
  • 开放-关闭原则:有一天你可能会在其他情况下调用回调

还有其他一些原则,但我认为这些是最重要的。

相关内容

  • 没有找到相关文章

最新更新