Responsibility Division in Object-Oriented Design

Imagine building a volume slider for a music app. The slider must remember how loud the volume currently is, draw itself on the screen at the correct position, and react when someone drags it. You could write all of that inside one large object. For a toy example that works, but it becomes hard to change the way the slider looks without accidentally breaking the way it stores its value, or the reverse. The Model-View-Controller pattern, usually called MVC, is a way of avoiding that tangle.

The MVC pattern starts from a general principle of object-oriented design: an object should have one clearly defined role with a limited realm of responsibility. Applied to graphical user interfaces, that principle produces three realms. MVC is short for Model-View-Controller, and each name labels one realm. The Model is the realm of state, the place where the component's data lives. The View is the realm of presentation, the part that draws that state on the screen. The Controller is the realm of event handling, the part that responds to user and other events.

Why split the component at all? Because the three concerns change for different reasons. The way the slider looks may change when a designer updates its appearance. The rule for what volume values are allowed may change for a different reason. The way the slider reacts to a drag may change again. When these concerns share one object, a change to one can disturb the others. Separating them keeps each change contained inside the realm it belongs to.

For the slider, the Model is the place where the current volume value lives. The Model does not draw anything, and it does not decide what to do when the mouse moves. It only holds the data and keeps it accurate. Because the state sits in its own object, any other part of the component that needs the volume asks the Model for it. Nothing keeps a separate copy that could fall out of step.

The volume numbers in the worked example are illustrative. The point is structural: the Model is the single source of the value, and every other part of the component reads from it.

The source notes that the View is often the component object itself, which makes it the easiest of the three parts to recognize. To draw correctly, the View has to consult the Model, because the Model holds the state and that state determines what appears on screen. The drawn knob position depends on the volume value stored in the Model, so the View keeps a reference to the Model object and reads the data when it paints.

Notice the direction of the relationship. The View reads from the Model when it draws. The View does not own the value, and it does not decide the value on its own. That division allows the same data to be presented in more than one way if the design calls for it.

The Controller is the least tidy of the three realms when MVC is used for Swing components. The source explains that its responsibilities are often split among several objects rather than gathered into one. These can include mouse and keyboard listeners that respond to input on the View, action objects that respond to menu commands or buttons, and listeners for higher-level events such as those produced by a slider. Each piece responds to something happening, and each one ultimately changes the state of the component.

The typical pattern is that the Controller responds to an event by modifying the Model. The View is then updated only indirectly, because the Model has changed and the View reacts to that change. The Controller does not paint the knob. It changes the data, and the change is shown through a separate route.

How does the View learn that a redraw is needed? The source says that in Java this is typically handled with events and listeners. The Model is set up to generate events when its data changes, and the View registers itself as a listener for those events. When the Model changes, an event is generated, the View is notified, and the View updates its appearance. The Model does not need to know how the View draws things. It only announces that its data has changed, and the View decides how to respond.

Now follow one complete update. The user drags the slider knob. The sequence below shows the order of messages. Read it from top to bottom: each arrow is a message sent after the one above it.