“模型”与“模型”之间的接口和“查看”

发布于 2024-10-23 12:16:33 字数 789 浏览 3 评论 0原文

程序具有视图和模型(宽松地使用术语),其中视图观察模型。该模型有一些状态,视图有一些映射到状态的 jpanels(某些状态每个都有几个相应的 jpanels)。使用卡片布局,一次显示一个 jpanel,状态更改或状态内的更改会将当前 jpanel 替换为另一个 jpanel。 program 有效,但对于视图和模型来说,假设存在以下情况似乎是不好的做法:正好 5 个状态和 7 个视图。这可以如何实施。


class Model implements Observable {
  State A, B, C;
  final int VIEW_A = 0, VIEW_B = 1, VIEW_C0 = 2, VIEW_C1 = 3; 
  int stateView;

//参数将是上面最后的整数之一 无效 setStateView(int stateView) { this.stateView = stateView; 通知观察者(); }

void getStateView() { 返回 stateView; } }

类 View 实现 Observer { 无效更新(Observable o){ //将使用上面的整数之一来识别要显示的正确jPanel setJPanel ( o.getStateView() ); } }

我认识到上面的代码是解决这个问题的一种糟糕的方式。这就是我在这里的原因。帮助?

A program has a view and a model (using the term loosely) in which the view is observing the model. The model has a handful of states, and the view has a handful of jpanels that are mapped onto the states (some states have several corresponding jpanels apiece). Using a cardlayout, one jpanel displays at a time, and a state change or change within a state will swap out the current jpanel for another. The program works, but it seems like bad practice for the view and model to assume that there are exactly 5 states and 7 views. How may this be implemented.


class Model implements Observable {
  State A, B, C;
  final int VIEW_A = 0, VIEW_B = 1, VIEW_C0 = 2, VIEW_C1 = 3; 
  int stateView;

//argument will be one of the final ints above void setStateView(int stateView) { this.stateView = stateView; notifyObservers(); }

void getStateView() { return stateView; } }

class View implements Observer { void update(Observable o) { //will use one of the ints above to identify the correct jPanel to display setJPanel ( o.getStateView() ); } }

I recognize the code above is an awful way of going about this. That's why I'm here. Help?

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

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

发布评论

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

评论(2

谜泪 2024-10-30 12:16:33

一些事情:

  1. 在使用模型来维护状态时,您正在正确使用MVC设计模式。

  2. 假设只有 5 个状态当然是可以的如果只有 5 个状态。我不同意你正在使用的另一种做法。我不会使用一堆 final int 声明,而是定义一个代表您的状态的 enum 。我认为这可能是您认为您的程序丑陋的主要原因。在我看来,这就是你决定不使用 enum 的原因。

  3. 这种设计的可扩展性不太好。如果您最终需要 147 个状态怎么办?这是值得思考的事情。一种选择是使用除单个整数之外的其他内容作为状态描述符。由于我不知道你在设计什么,所以我很难在这一点上给出好的建议。

编辑:解决另一个建议使用调解器模式的答案:我认为这对于这个简单的应用程序来说是多余的。您的模型很简单,并且状态的维护并不太复杂。设计很重要,但过度设计也会导致陷阱。

祝你好运,

-tjw

A few things:

  1. In using your model to maintain state, you are using the MVC design pattern correctly.

  2. Assuming there are only 5 states is certainly ok if there are only 5 states. I do disagree with another practice you are using. Instead of using a bunch of final int declarations, I would define a enum that represents your state. I think that this could be a major reason why you think your program is ugly. It is, in my opinion, and your decision to not use enum is the reason.

  3. This design is not very extensible. What if you eventually need 147 states? This is something to think about. One option is to use something besides a single integer as your state descriptor. Since I don't know what you're designing, it's hard for me to give good suggestions on this point.

Edit: to address another answer posted suggesting use of the Mediator pattern: I think this is overkill for this simple of an application. Your model is straightfoward, and your maintenance of states is not overly complex. Design is important, but going overkill on your design can lead to pitfalls as well.

Good luck,

-tjw

单挑你×的.吻 2024-10-30 12:16:33

在中间插入一个类,专门负责将状态映射到视图。让此类通过告诉视图显示哪个面板来对状态变化做出反应。这将映射逻辑保持在一个位置 - 模型对视图一无所知,视图对状态一无所知。这是 Mediator 模式的变体。

Insert a class in the middle with the sole responsibility of mapping state to view. Have this class react to state changes by telling the view which panel to show. This keeps the mapping logic in a single place - the model knows nothing about views, and the view knows nothing about states. This is a variant of the Mediator pattern.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文