java MVC +可否决/递延财产

发布于 2024-09-26 16:57:47 字数 1573 浏览 1 评论 0原文

我有一个接口 FooModel 和一个具有一些简单属性的类 DefaultFooModel。我陷入了布尔启用属性,因为我想让它被否决/推迟:

public interface FooModel {
   public boolean isEnabled();
   /** returns old value */
   public boolean setEnable(boolean enable); 

   public void addFooListener(FooModel.Listener listener);
   public void removeFooListener(FooModel.Listener listener);

   public interface Listener {
      public void onFooEnableUpdate(boolean newEnable, boolean oldEnable);
   }
}

我想要的是模型 M 成为启用的访问中心点代码>属性。但以下是我想要发生的事件序列:

  1. 视图 V(或模型 M 的任何用户)在任意线程上调用 FooModel.setEnable(enable) 。
  2. FooModel 可以:

    a.立即以任意顺序在每个侦听器上调用 onFooEnableUpdate(newEnable, oldEnable)

    b.启动一个可能很长的事件序列,另一个实体(例如控制器 C)可以决定是否启用,并以某种方式让 FooModel 知道,从而可以更新 enable 属性,然后我们照常进行(a )上面。

问题是,我不知道如何去做这件事。

方法 1:执行此操作的机制不应成为模型界面的一部分。相反,我的 DefaultFooModel 有一个接受 FooController 的实现:

public interface FooController {
   public void onFooEnableRequest(boolean newEnable, boolean oldEnable);
}

当调用 DefaultFooModel.setEnable() 时,它会调用 FooController.onFooEnableRequest() 。控制器预计会立即返回,但可能需要一些时间来消化请求,然后调用 DefaultFooModel.updateEnable() ,这会导致真正的 onFooEnableUpdate() 获取叫。

方法 2: 在 FooModel 界面中构建一些内容,但我不确定是什么。

方法 3: 不要在 FooModel 中构建任何内容,只需让它处理常规属性。相反,让 Controller 监听 FooModel.onFooEnableUpdate() 并立即将 setEnable 重写为旧值,然后稍后调用 FooModel.setEnable() 以设置新值。

有什么建议吗?

I have an interface FooModel and a class DefaultFooModel that have a few simple properties. I am getting stuck on a boolean enable property because I want to have this be vetoable/deferred:

public interface FooModel {
   public boolean isEnabled();
   /** returns old value */
   public boolean setEnable(boolean enable); 

   public void addFooListener(FooModel.Listener listener);
   public void removeFooListener(FooModel.Listener listener);

   public interface Listener {
      public void onFooEnableUpdate(boolean newEnable, boolean oldEnable);
   }
}

What I want is for the model M to be the central point of access for the enable property. But here's the sequence of events that I want to occur:

  1. view V (or any user of the model M) calls FooModel.setEnable(enable) on an arbitrary thread.
  2. FooModel may either:

    a. immediately call onFooEnableUpdate(newEnable, oldEnable) on each of its listeners in arbitrary order

    b. start a potentially long sequence of events whereby another entity (e.g. controller C) can decide whether to enable, and somehow let FooModel know, whereby the enable property may be updated and then we proceed as usual in (a) above.

The thing is, I'm not sure how to go about doing this.

Approach 1: the mechanism to do this shouldn't be part of the model's interface. Instead, my DefaultFooModel has an implementation which accepts a FooController:

public interface FooController {
   public void onFooEnableRequest(boolean newEnable, boolean oldEnable);
}

When DefaultFooModel.setEnable() is called, it then calls FooController.onFooEnableRequest(). The controller is expected to return immediately, but can take its time to digest the request, and then later call DefaultFooModel.updateEnable() which causes the real onFooEnableUpdate() to get called.

Approach 2: build something into the FooModel interface, but I'm not sure what.

Approach 3: Don't build anything into FooModel, just have it handle a regular property. Instead have the Controller listen to FooModel.onFooEnableUpdate() and override setEnable right away to the old value, then call FooModel.setEnable() later to set the new value.

Any advice?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

樱花细雨 2024-10-03 16:57:47

使 FooModel 成为一个类而不是一个接口。

我认为使 FooModel 成为一个接口的问题是需要将复杂的逻辑编码到侦听器机制中。强制任何实现接口的人也必须实现侦听器逻辑通常不是一个好主意。

相反,使 FooModel 成为一个类,自己实现侦听器接口,并创造性地创建可以在需要实现更具体功能时重写的公共方法。

  • notifyListeners(boolean newEnable, boolean oldEnable) 默认情况下通过调用以下方法通知所有侦听器,但可以重写以不执行任何操作,或者有条件地通知
  • notifyListener(Listenerlistener, boolean newEnable, boolean oldEnable) 通知特定侦听器

Make FooModel a class instead of an interface.

The problem I see with making FooModel an interface is the complex logic that needs to be coded into the listener mechanism. It's generally not a good idea to force anyone who implements the interface to have to implement the listener logic as well.

Instead, make FooModel a class, implement the listener interface yourself, and creatively create public methods that can be overridden where you need to implement more specific functionality.

  • notifyListeners(boolean newEnable, boolean oldEnable) notifies all listeners, by default by calling the following method, but could be overridden to do nothing, or to notify conditionally
  • notifyListener(Listener listener, boolean newEnable, boolean oldEnable) notifies a specific listener
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文