I've been stuck on this particular part of my design and I'd like some input as to how I should approach it. My program consists of courses LeerTrajecten and elements Elementen. Both of these objects can exist independently, but elements can also be added to a course.
Element in itself is an abstract superclass of objects like Document, Casus, etc.
(1)
When an element is added to a course, a course-element LeerTrajectenElement is create which contains the TrajectCode, ElementCode, an own unique code consisting of the previous two fields and some other data (DisplayNaam, DisplayOmschrijving).
In the GUI (Spring), there are a few tabs (JTabbedPane) dedicated to managing these courses and elements. Every tab has an overview and a detailpanel. In this overview there's a JTable to display every existing Element or Traject.
This is merely intended as a way to put the program into perspective (LeerTrajectElement) and to show that there might be multiple JTable active at the same time, but on different tabs.
(2)
I've also got managers whose sole purpose is to manage their respective object (LeerTrajectManager manages LeerTraject, ElementManager manages Element, etc). These managers are known to the Domeincontroller which serves as a general façade for the entire domain. Requests from the GUI are sent to this DomeinController which sends the request, if it's meant for a manager, to the correct one.
That's the basic outline of my program, I'll include some diagrams as visual aid.
(1)
(2)
I hope I have provided adequate information concerning the current setup of the project.
For some reason my model isn't displaying correctly, but the DomeinController holds the 3 managers (it isn't shown in the overview but the associations are there).
As you can see in picture 2, every manager holds a tableModel. TableModels are defined like this:
MyAbstractTableModel extends AbstractTableModel and provides basic implementation so specific implementations can derive from this class while only providing the very basic needs.
This is where we're getting to the point: Currently every manager holds its own tableModel and we (the teacher) decided we should abstract this out into a manager. I've been working on an implementation for this, but I felt like I got something fundemental wrong: these tableModels can be generated for a few different purposes: either you want all elements, or you want all elements linked to a course, or you want all elements linked to a specific course, etc etc.
In order to obtain something like this, I've tried creating two getTableModel methods. The first one only took an enum {LEERTRAJECT, ELEMENT, LEERTRAJECTELEMENT } as argument, while the second one took an additional List<E> as argument. Doing this would allow me to generically add data to the request, data which could be gathered earlier by the appropriate manager (and thus only sending resultset data to the TableModelManager.
This approach ended up with a lot of Switch statements for every method in my TableModelManager to determine what should happen with it and what tableModel should be used. The code became pretty unclean so I figured that this is probably not the way I want it to be.
As to why we should introduce a manager in the first place: appearantly our tableModels are now hard linked to our respective managers and we should try to avoid this.
So, in conclusion: I have several managers, all of them holding a TableModel to display their respective data. I would like to centralize this by holding the current TableModel in a TableModelManager and generate tablemodels trough this object. Other managers would simply hold a reference to the TableModelManager and tell him the data has been changed or ask for the appropriate model.
How should I approach this?
PS: I realize this is more of a design question, so if I should place this in a different site on the stackexchange network just let me know and I'll delete this.
PPS: I'm sorry for the non-english parts, my teammates refused to use english only.
