调解者模式或责任过多
在我的应用程序中，我有几个必须相互了解的组件，例如菜单栏和工具栏，它们都需要了解表以添加或删除作业，并找出选择了哪个作业。
因此，我创建了一个名为 guiMediator 的对象，我将其传递给每个对象，并且它们向该对象注册自己，以便可以使用该对象相互联系。 它还负责在添加新作业或后台工作人员完成其工作时触发事件。
由于它对系统了解很多，这种用法是否在一个地方承担了过多的责任，或者这是该模式的正确用法？
In my application, I have several components that have to know about each other, such as a menu bar and a tool bar that both need to know about the table to add or remove jobs and also to find out which job is selected.
So, I created a object called guiMediator that I pass to every object and they register themselves with it so that they can reach each other using that object. It is also responsible to fire events when new jobs are added or background workers finish their job.
Since it knows a lot about the system, is this type of usage too much responsibility in one place, or is this the correct usage of the pattern?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
听起来比另一种更好……但是嘿，我娶了最不丑的妹妹;-)
Sounds better than the alternative... But hey, I married the least ugly sister ;-)
通常我会使用命令模式来实现类似的功能：
因此，您的命令了解所有视图组件，但视图组件唯一需要知道的是当用户完成给定操作时要执行哪个命令。
Normally I would use the command pattern for something like that:
So your commands know about all your view components, but the only thing your view components need to know is which command to execute when a given action is done by the user.
我会使用被动视图，您可以在此处阅读有关内容。
请注意，除了 UI 界面之外，没有任何地方知道按钮、复选框等。 您可以使用接口来抽象实际的实现。
这会给你带来几个好处。 首先，它将记录您的代码如何与 UI 交互，为您提供一个实现模拟对象以用于自动化测试的位置，最后在更改 UI 方面提供更多的自由度。
例如，用可点击面板代替命令按钮。 然后，表单将开始传递来自面板的单击事件而不是按钮。 表单可能仍然不知道每个小部件应该执行的实际命令。 UI 对象负责处理这个问题。
I would use a Passive View which you can read about here.
Note that nowhere does anything beyond the UI Interface knows about buttons, check boxes, and the like. You use the Interface to abstract the actual implementation away.
This will give you several advantage. First it will document how your code interacts with the UI, give you a place to implement mock objects to use for automated testing, and finally allow much more latitude in changing the UI.
For example substituting clickable panels instead of command buttons. The form will then just start passing the click events from the panels instead of the button. The form can remain ignorant of the actual command each widget is supposed to do. The UI Object takes care of that.