我正在对我的项目进行建模,随后我将利用 UML 在 Java 中实现该项目。我的项目的重点是健身房的管理。目前,我正在对我的 GoF 观察者图进行建模。根据我的理解,让我的图形控制器直接与模型(实体)通信似乎不合适——如果我错了,请纠正我。
相反,如果我让我的应用程序控制器实现观察者模式,当练习改变其状态时,如何有效地通知图形控制器?图形控制器负责处理输入并显示应用程序 GUI 视图的输出,通过 bean 类与应用程序控制器进行通信。
另一方面,应用程序控制器扮演“做工作”的角色。它通过 bean 从图形控制器检索数据并执行必要的活动,例如拒绝请求或删除练习。此外,它还可以通过其他类(DAO)从数据库获取数据,这些类与 bean 的类一样,在本例中没有讨论。
随后,我有了另一个想法,就是:
我引入了一个ExerciseInventory类,它有两个列表作为属性:exList,继承自ExerciseCatalogue类(包含我数据库中的所有练习),和activeExerciseList,包含状态设置为活动的练习(状态可以是活动/暂停) )。在这种情况下,具体观察者监视每个练习的状态,并在发生任何变化时更新 activeExerciseList。
但是,我在这种方法中遇到了一个问题:不幸的是,观察者模式传统上假设具体观察者和具体可观察者(在本例中为“实体”练习)之间的重数为 1..1。在我的情况下,多重性是 1..N,因为具体观察者观察了很多练习,并且我不确定这是否仍然是一个可行的想法。
这是建模:
首先,让我们澄清多重性。对于每个关联,不存在单一的多重性,例如1..1 在具体观察者和具体可观察者之间,但是有两个多重性,关联的每一端各有一个。
在可观察量和观察者的情况下,重数一般分别为
0..1
和 *
,因为每个可观察量可以有多个观察者,并且每个观察者最多可以观察到一个可观察量,但只要满足以下条件,就可能无法观察到它没有附加到可观察的对象上。
此外,GoF 在第 297 页明确提到,该设计可能允许同一个观察者观察多个可观察量。那么重数将分别是
*
和 *
。执行此操作的常用技巧是可观察对象调用 update()
将其自身作为参数传递。所以你的第三个设计将是完全有效的。
顺便说一句,您不需要复制具体可观察量和具体观察者之间的关联,因为这些关联也是继承的。
前两种选择取决于您选择的架构模型:
一种非常流行的方式是 MVC,其中控制器处理输入,视图管理显示,模型管理实体数据。视图(在您的例子中是图形控制器)可以很好地订阅模型。
另一种流行的模式是实体边界控制模式,其中控制器驱动业务逻辑(应用程序控制器),而边界管理用户界面。
因此这两种方法都可以辩护。由您选择建筑模型,然后决定什么可以看到什么或不能看到什么。