我一直停留在设计的这一特定部分,我希望获得一些有关如何进行设计的意见。我的程序包括课程LeerTrajecten和元素Elementen。这两个对象可以独立存在,但是元素也可以添加到课程中。
Element本身是DocumentCasus等对象的抽象超类。

(1)
将元素添加到课程时,将创建一个包含LeerTrajectenElementTrajectCode的课程元素ElementCode,这是一个由前两个字段和一些其他数据(DisplayNaam,)。

在GUI(春季)中,有一些选项卡(DisplayOmschrijving)专用于管理这些课程和元素。每个选项卡都有概述和详细信息面板。在此概述中,有一个JTabbedPane可以显示每个现有的JTableElement

这仅是将程序置于透视图(Traject)中并显示可能同时存在多个LeerTrajectElement且位于不同选项卡上的一种方式。

(2)
我也有一些经理,他们的唯一目的是管理各自的对象(JTable管理LeerTrajectManagerLeerTraject管理ElementManager等)。这些管理器为Element所熟知,它是整个域的通用外观。来自GUI的请求将发送到此Domeincontroller,如果是针对管理员,则该DomeinController会将请求发送到正确的请求。

那是我程序的基本轮廓,我将包括一些图表作为视觉辅助。

(1)


(2)

我希望我提供了有关该项目当前设置的足够信息。
由于某种原因,我的模型无法正确显示,但是DomeinController包含3个管理器(总览中未显示,但存在关联)。

如图2所示,每个经理都拥有一个tableModel。 TableModels的定义如下:



MyAbstractTableModel扩展了AbstractTableModel并提供了基本的实现,因此可以从此类派生特定的实现,同时仅提供非常基本的需求。

这是我们要讲的重点:
当前,每个经理都拥有自己的tableModel,我们(老师)决定将其抽象为经理。我一直在为此实现一个实现,但是我觉得我犯了一些根本性的错误:可以为几个不同的目的生成这些tableModels:要么想要所有元素,要么想要链接到课程的所有元素,或者希望将所有元素链接到特定课程等。

为了获得类似的内容,我尝试创建两个getTableModel方法。第一个仅将枚举{LEERTRAJECTELEMENTLEERTRAJECTELEMENT}作为参数,而第二个仅将另一个List<E>作为参数。这样做可以使我将数据一般添加到请求中,这些数据可以由适当的管理者更早地收集(因此仅将结果集数据发送到TableModelManager

这种方法最终在我的Switch中的每个方法中都有很多TableModelManager语句,以确定应该发生什么以及应该使用哪种tableModel。代码变得非常不干净,所以我认为这可能不是我想要的那样。

关于我们为什么首先要引入经理的原因:显然,我们的tableModels现在已经硬链接到我们各自的经理,我们应该避免这种情况。

因此,总而言之:我有几个经理,每个经理都拿着TableModel来显示各自的数据。我想通过将当前TableModel保留在TableModelManager中并通过该对象生成表模型来对此进行集中化。其他管理人员只需持有对TableModelManager的引用,并告诉他数据已更改或要求使用适当的模型。

我应该如何处理?

PS:我意识到这更多是一个设计问题,因此,如果我将其放置在stackexchange网络上的其他站点中,请告诉我,然后将其删除。

PPS:对于非英语部分,我感到抱歉,我的队友拒绝只使用英语。

最佳答案

没有详细的分析,


您可以通过让每个元素实现一个通用接口来实现strategy pattern来挽救enum方法,如here所示。
作为使用管理器的具体示例,此TestTable使用MyObjectManager的实例来管理JTable中每行一个单选按钮。

09-18 09:37