I might be misunderstanding MVC, so forgive me if that is the case.
This is my program structure (Java/Swing): I have a JTable (View) that is pointed to by a custom linked list (Model). When the user tries to add something to the JTable, the action listener (Controller) updates the linked list (Model) which updates the JTable (View).
Here’s my issue: The linked list should be able to function independently of the JTable, but it doesn’t. Let’s say I decided to get rid of the user interface and just use the linked list for internal stuff within the program (The linked list has other properties and functions outside the scope of MVC). That should be able to work, because the linked list’s FUNCTION is independent of the JTable’s function, yet I would have to edit a lot of code to do so (or have a bunch of code that no longer does anything) because of MVC.
So am I misunderstanding MVC completely, just a little bit, or are the dependencies a price I have to pay?
NOTE: This is a simplified view of my project. In real life, there are other objects in the model and more than just a JTable in my interface. Also, the linked list has other thigns that get updates other than the number of objects.
You seem to have the dependency between your Model and your View the wrong way around. A Model does not know about the existence of a View, at most the model knows that some other component in the system might want to know about changes to the model.
In the MVC pattern, either the Controller informs the View that it should update itself, or the View asks the Model to notify it about changes. In the latter case, the communication from the Model to the View goes through a generic mechanism that allows a one-to-many communication without the Model knowing (or caring) about how many and which components it talks to. This mechanism is typically an event mechanism or an implementation of the Observer pattern.
A model is view-agnostic, so your feelings are pointing you into the right direction.
The controller decides, which model and which view to use. It injects the model into the view, and optionally registers the view as an Observer for the model. Then the controller passes control to the view.
Then the model is changed by the controller, usually invoked by an event in the view. If the Observer pattern is used, the model notifies the view directly, which re-renders itself without further controller interaction, otherwise the controller gives control back to the view.
How I’ve addressed this issue is to have the data in base collection (a linked list in your case) as the real data model. Then create a TableModel instance that is a thin wrapper around the data model. Your view and controller don’t need to change.
This way, if you don’t need the UI anymore, you can still work directly with the linked list. Or if you come up with a different way to represent the same data, you could create a different TableModel to correspond with this new view, but still using the same backing data model.
1