Kon*_*rus 6 language-agnostic design-patterns circular-dependency
我正在用Java编写一个复杂的GUI,其中有许多组件在几个屏幕上工作,并与共享的逻辑和模型进行交互.显然,"gui"和"controller/logic"之间存在一些循环依赖关系:GUI中的用户操作被转发到控制器,控制器执行某些任务,然后需要在所有GUI中反映这些更改.在后台可能会发生一些事情,使控制器推送更新到GUI.等等.
现在,这是我的问题.监听器或观察器模式非常适合将更新推送到GUI.可以让我的GUI直接依赖于具体的控制器类吗？为什么/为什么不呢？有(并且总是会)只有一个这样的控制器.有像十几控制器调用的图形用户界面需要轮询状态和执行行动 - 我不爱的平凡回调接口少数那总是要的想法只有一个实现,也不是一个巨大的回调接口为所有各种行动.
可以让我的GUI直接依赖于具体的控制器类吗？为什么/为什么不呢？
否:因为松耦合是良好设计的基础.取决于抽象.根据实现,不可能在不重新编译依赖项的情况下将一个实现替换为另一个实现.紧密耦合任何两个类都会阻碍未来的灵活性.
是的:这是一个判断电话.如果松散耦合肯定没有未来的好处,并且太昂贵而无法证明,那么请将其结合起来.
但是真的尽量不要.让GUI依赖于控制器是一个有效的设计决策.但总是依赖于抽象,从不实现.来吧......你知道的.我的意思是,好吧,如果没有人想要切换控制器,那么你没有通过使用接口获得任何东西.除了安心,知道你写了更整齐,更少耦合的代码.并且可以说更容易测试.
至于如何选择GUI和控制器之间的通信,这是一个折腾.您可以使用事件,但是将它们连接起来是一种阻力,它们不会跨越应用程序边界.但通过使用事件,您可能会觉得您有最松散的耦合.除了最初连接事件之外,GUI和控制器永远不需要相互寻址(抽象).那可能会感觉很好.或者你可以使用对接口的方法调用,这可能感觉像一个稍微紧凑的耦合,但它真的几乎没有.无论如何,X 必须知道Y的事情才能让他们沟通.
GUI和控制器之间的循环依赖是可以的(在抽象!).MVC模式有许多变体.每次我使用它,我都会根据自己的需要/情绪来塑造它.也就是说,我确实试图避免循环依赖.我更喜欢将依赖关系限制在一个方向.或者根本没有!
例如,在我当前的项目中,控制器知道视图,但视图完全不知道控制器退出.控制器会触发视图的事件,并通过视图绑定的单个状态对象将数据传回给它们.状态类是视图唯一依赖的东西.控制器唯一知道的是视图的界面和状态对象的类型.这些东西在外部模块中定义,以便可以完全删除视图模块,控制器仍然可以编译,反之亦然.这是一个非常松散的耦合.几乎没有(双方都取决于第三个模块).
有些人以另一种方式做到这一点.
避免具体依赖性的原因