Use MVC, SOLID Principles, and Design Patterns in Java

You've just discovered SOLID principles, but before we dive in, there needs to be a structure for your code that makes these principles easy to apply. Luckily, there is MVC!

What is MVC?

MVC is a software architecture approach. It divides the responsibilities of the system into three distinct parts:

• Model: The model holds the state information of the system. 

• View: The view presents the model information to the user. 

• Controller: The controller makes sure that user commands are executed correctly, modifying the appropriate model objects, and updating the view objects.

How does this work in practice? Let's look at going to a restaurant for a moment. First, someone greets you at the door and asks you to wait until a table is ready. Then they take you to your seat. Another person takes your order, and eventually delivers it. Another person cooks it while another cleans up after you've gone. Finally, another person washes all the cookware and dishes.

Each person has a clear responsibility for providing you with your dining experience. You don’t need to interact with everyone involved in this system. The dishwasher doesn’t come out of the back and help seat you. A single person isn’t responsible for doing every job.

Based on the example, here’s some Java that would violate the SOLID principles:

class RestaurantWorker {
   public void seatPatrons();
   public void takeOrder();
   public void cookOrder();
   public void deliverOrder();
   public void cleanTable();
   public void washDishes();
};

This code has a single object (person) in the system doing all of the work. If you add jobs, I'm sure you can guess where they go.

SOLID tells you to split out responsibilities, and model-view-controller (MVC) indicates where those splits should be. It is the basis of your system's architecture. Each class in the system falls into one of the three categories and therefore has a specific purpose.

What Goes in the Model (M)?

State information is kept in model classes. These are the items being viewed and manipulated. Also, if you need to store anything long term, it will be the model objects. If you were to program the restaurant example, a couple of model objects would be a customer's order, or how many pounds of potatoes are in the pantry:

class CustomerOrder {
    List<MenuItems> selectedItems;
    float baseCost;
    float tax;
};

class PantryItem {
    String name;
    float currentInventoryLevel;
    float reorderLevel;
};

Or, if you consider our game, the state is all the information that tells the current "story." How many players are there? Which player holds which card? Which cards are still in the deck? All of those ideas added together make up the state of the game.

What Goes in the View (V)?

The view is how the model is presented and interacted with by the user. It's the most likely thing to change. You want a clear distinction in the way this part interacts with the rest of the system. At the restaurant, this would be the menu, but also the greeter, and wait staff, and anyone else you would interact with directly. If you were building an application, this would be your user interface or UI. You might think of one of the views like this:

class Greeter {
    public void askHowManyPeopleToSeat();
    public void reportEstimatedWaitTime();
    public void takeCustomersToTable();
}

All of the above reflect interactions that the user would see.  

What Goes in the Controller (C)?

The controller is where the flow of the application is managed. All the sequencing of interactions between the user and the system is here. The user interacts with the view, which then interacts with the controller. The controller then makes the appropriate modifications to the model objects, makes new ones, or deletes no longer needed ones. In the restaurant example, the controller would be the set of rules, established by the owner or manager, on how to take care of a guest:

class ProcessCustomer {
    public void customerGreeted();
    public void customerSeated();
    public void orderTaken();
    public void orderDelivered();
    public void patronSatisfactionChecked();
    public void billPresented();
    public void billPaid();
};

This would represent the workflow, or sequence of steps the customer would be led through.

What Are the Advantages of MVC?

If you follow this MVC pattern, you build a system with nice, clear responsibilities. One of the benefits of using MVC is that it follows the S principle in SOLID.

Single responsibility. We'll look at each responsibility in a moment. But the big idea is that classes that are models do one thing, while those that are views or controllers do others.

But it also follows the other principles as well. For example, since the view is separated, it is easy to add new user interface elements without having to modify the model or controller. Which principle is that?

Right! And the other principles are used as well.

Let's Recap! 

• MVC follows the "S" of the SOLID principles by separating responsibilities.

• The model contains state information.

• The view contains the elements that interact with the user.

• The controller makes sure the sequence of steps occurs correctly.

In the next chapter, we will concentrate on creating the model classes in our card game.