Views are tied to models. Since representations visualize models, they must have intimate knowledge of the model, there simply is no way. Some views are common, and they have “common” models. Here you can try to match your actual model with a common one, so that the "general" view can use your data. But even with these generalized models, views are still closely related to them.
Data management models, state. Although the view has a deep knowledge of the model, the model is agnostic. It is just the same. Thus, you can have several views for the same model.
However, the model must inform others of changes to the model. Usually in java you use PropertyChangeListener. This mechanism allows the model to simply shout about wholesale changes, and anyone can listen to these changes and act on them, for example, your opinion.
A simple example is that a game object can take damage from a bullet, and it has decreased to below 50% health. The view can see that the health has been reduced and the image of the model has changed (for example, adding smoke or something else).
The controller is usually closely associated with the view and model. He knows the possibilities of representation (for example, size and other areas of interest), and he knows how to change the model. For example, when you click the mouse, the controller converts the mouse point into a coordinate relative to the view, and it determines which object was clicked. When it determines the object that was clicked, it can set the model for the object, for example, "selected."
The model then reports that the "selected" property has been changed. The view sees this, finds the bounding box for the model that has changed, and invalidates that box on its display.
Finally, Java comes and says, "Hey, Rect 10,10,100,100 need to be drawn." And the look finds the models in this rectangle, draws a new view of the object with the “selected” border, or something else.
This is how the whole cycle works.