The way it was explained was through the use of events and the publish/subscribe model. Basically, the model would just be the data and it would have no knowledge of the view/GUI/UI. The model is typically just an abstract object that operates on its data and can perform operations and whatnot.

The view is a different class that responds to changes in the model and usually displays this data to the user. Previously, I did not know how this could occur without coupling between the view and model but having it explained with events clears that confusion up a lot. Does this mean that the model contains public events that itself raises when something interesting happens? For example, if we were programming a game of Chess, when a piece was moved, the model would raise the event of `PieceMoved` with the necessary information (which piece, moved from where to where, etc.) and the view could subscribe to such an event and then show an animation of the piece moving from its old square to its new square.

The part that still confuses me is the exact nature of the controller. I'm having trouble understanding how it supplies the model and view with new information. I imagine the controller contains references to the model and view. Keeping with the Chess example, would the controller just respond to user input (for example to move a piece) and then just suggest to the model what piece wants to move to where? Then the model takes this information, sees if it's a legitimate move, and if so, update the model accordingly, raise the `PieceMoved` event, to which the view reacts and updates the graphical realm accordingly?

Lastly, how does the controller find out which piece is trying to be moved? It seems like that type of thing is heavily tied to the view (let's say moving involved first clicking the piece you wish to move and then the destination square). I imagine the controller would respond to a mouse click and sends those coordinates to the model but how would the model know how to translate those coordinates to find which piece was selected? Isn't that heavily tied to the view? It seems like the view would have to perform some logic processing instead of simply responding to the model and controller but then it wouldn't be a proper view anymore (instead a view/model mix).