title: Improving design by extracting multiple TableModels into a single TableModelManager
body: <p>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 <code>LeerTrajecten</code> and elements <code>Elementen</code>. Both of these objects can exist independently, but elements can also be added to a course.
  <code>Element</code> in itself is an abstract superclass of objects like <code>Document</code>, <code>Casus</code>, etc.</p>
  
  <p>(1)
  When an element is added to a course, a course-element <code>LeerTrajectenElement</code> is create which contains the <code>TrajectCode</code>, <code>ElementCode</code>, an own unique code consisting of the previous two fields and some other data (<code>DisplayNaam</code>, <code>DisplayOmschrijving</code>).</p>
  
  <p>In the GUI (Spring), there are a few tabs (<code>JTabbedPane</code>) dedicated to managing these courses and elements. Every tab has an overview and a detailpanel. In this overview there's a <code>JTable</code> to display every existing <code>Element</code> or <code>Traject</code>.</p>
  
  <p>This is merely intended as a way to put the program into perspective (<code>LeerTrajectElement</code>) and to show that there might be multiple <code>JTable</code> active at the same time, but on different tabs. </p>
  
  <p>(2)
  I've also got managers whose sole purpose is to manage their respective object (<code>LeerTrajectManager</code> manages <code>LeerTraject</code>, <code>ElementManager</code> manages <code>Element</code>, etc). These managers are known to the <code>Domeincontroller</code> which serves as a general façade for the entire domain. Requests from the GUI are sent to this <code>DomeinController</code> which sends the request, if it's meant for a manager, to the correct one.</p>
  
  <p>That's the basic outline of my program, I'll include some diagrams as visual aid.</p>
  
  <p>(1)
  <img src="https://i.stack.imgur.com/tHRT3.jpg" alt="enter image description here"></p>
  
  <p>(2)<img src="https://i.stack.imgur.com/Pyp0U.jpg" alt="enter image description here"></p>
  
  <p>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 <code>DomeinController</code> holds the 3 managers (it isn't shown in the overview but the associations are there).</p>
  
  <p>As you can see in picture 2, every manager holds a tableModel. TableModels are defined like this:</p>
  
  <p><img src="https://i.stack.imgur.com/zzfGP.jpg" alt="enter image description here"></p>
  
  <p><code>MyAbstractTableModel</code> extends <code>AbstractTableModel</code> and provides basic implementation so specific implementations can derive from this class while only providing the very basic needs. </p>
  
  <p>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 <strong>all</strong> elements, or you want all elements <strong>linked to</strong> a course, or you want all elements linked to a <strong>specific</strong> course, etc etc.</p>
  
  <p>In order to obtain something like this, I've tried creating two <code>getTableModel</code> methods. The first one only took an enum {<code>LEERTRAJECT</code>, <code>ELEMENT</code>, <code>LEERTRAJECTELEMENT</code> } as argument, while the second one took an additional <code>List&lt;E&gt;</code> 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 <code>TableModelManager</code>.</p>
  
  <p>This approach ended up with a lot of <code>Switch</code> statements for every method in my <code>TableModelManager</code> 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.</p>
  
  <p>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.</p>
  
  <p>So, in conclusion: I have several managers, all of them holding a <code>TableModel</code> to display their respective data. I would like to centralize this by holding the current <code>TableModel</code> in a <code>TableModelManager</code> and generate tablemodels trough this object. Other managers would simply hold a reference to the <code>TableModelManager</code> and tell him the data has been changed or ask for the appropriate model.</p>
  
  <p>How should I approach this?</p>
  
  <p>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.</p>
  
  <p>PPS: I'm sorry for the non-english parts, my teammates refused to use english only.</p>