title: How to process selections from different providers via the Eclipse Selection Service while maintaining loose coupling?
body: <h3>TL;DR: Is there a way, preferrably adhering to design pattern best practices, to process <code>ISelection</code>s from multiple <code>ISelectionProvider</code>s in an <code>ISelectionListener</code> without breaking loose coupling, and without guessing (type checks, casting)?</h3>
  
  <p>In my Eclipse RCP 3.7 application, I have two <em>views</em> and one (<a href="http://eclipse.org/gef/gef_mvc/" rel="nofollow">GEF</a>) <em>editor</em>. The views contain checklists which allow the user to control the contents of the editor via selection. Assuming the editor displays university staff hierarchies, one view would allow to select the departments whose staff should be displayed, the other would allow to select the current degree levels for which staff should be displayed.</p>
  
  <p>I.e., if the user selected <em>Computer Science</em> and <em>English Literature</em> in one view, and <em>Post-Doc</em> and <em>Full Professor</em><sup>*</sup> in the the other, the editor would display staff (as, e.g., nodes) which are either Post-Docs or Full Professors from the CS or EngLit departments. The model, however, contains all staff from all depts.</p>
  
  <p>I've implemented views and editor according to <a href="https://eclipse.org/articles/Article-WorkbenchSelections/article.html" rel="nofollow">Eclipse Workbench: Using the Selection Service</a>: The editor has an <code>org.eclipse.ui.ISelectionListener</code>, the views both implement <code>org.eclipse.jface.viewers.ISelectionProvider</code>. The views maintain a list of listeners, which are notified in a loop whenever a selection changes: </p>
  
  <pre>((ISelectionChangedListener) listeners.getListeners()[i]).selectionChanged(
          new SelectionChangedEvent(DeptView.this, 
          new StructuredSelection(<b>{selection}</b>)))
  </pre>
  
  <p>I've tried the following implementations so far, but am not happy with either.</p>
  
  <ol>
  <li><p>For <code>{selection}</code>, use a custom class (e.g., <code>DeptSelection</code>), which encapsulates the selected elements, or rather the model elements they point to. I <em>think</em> that <strong>this breaks loose coupling</strong>, as <code>DeptSelection</code> would be defined in the <em>Dept Plugin</em>, which would be separate from the <em>Editor Plugin</em>, and at the same time I want to allow clients to add extensions for whose selections the listener would also be able to listen.</p></li>
  <li><p>For <code>{selection}</code>, simply pass the selected elements (in this case via <code>org.eclipse.jface.viewers.CheckboxTableViewer#getCheckedElements()</code>), and do the processing in <code>ISelectionListener#selectionChanged()</code> in the editor. This is <strong>clumsy</strong>, as it involves a lot of guessing: type checks, casting, etc. Also, for this solution I then "save" the selections in an abstract util class <code>SelectionUtil</code>, which is read in the editor (here, the root edit part's contents edit part) to add the respective model elements to the list returned by <code>AbtractEditPart</code>'s <code>getModelChildren()</code>. I'm (a) <strong>not sure whether the use of an abstract util class breaks loose coupling</strong>, and (b) whether having <strong>an abstract util class at all is a good design pattern</strong>.</p></li>
  </ol>
  
  <h3>Hence my question: Is there a non-clumsy way, preferrably adhering to design pattern best practices, to process multiple <code>ISelection</code>s without breaking loose coupling?</h3>
  
  <p><sub><sup>*</sup>I know, not the most accurate example, as "Full Professor" and "Post-Doc" aren't exactly degrees.</sub></p>