When you pack for a trip, do you throw all your clothes into your suitcase in a big messy heap? If your answer is ‘yes’, then you’re not alone. Many of us embrace the ‘blob’ method while travelling, and it works because suitcases aren’t very big. When it’s time for pyjamas we can go through each item one at a time, and it won’t take long to find our big fuzzy pants.

The blob strategy doesn’t work as well when you’re organizing your closet. And imagine if retail stores displayed clothing in a giant pile! We’d never buy new jeans if we had to wade into a sea of scattered shirts, sweaters and socks to find the ideal pair.

Long story short: the bigger the system, the more structure it needs. The same is true for software.

DESIGN PATTERNS

Design patterns are the equivalent of the shelves, hangers, and boxes in your closet. They’re high-level solutions for organizing your code that tell you what sections of code are responsible for what actions. Design patterns keep your code neat and tidy, preventing unrelated tasks from spilling over into each other!

There are many different patterns, and the one you choose depends on the type of problem you’re having.

MODEL-VIEW-CONTROLLER

“Model-View-Controller” (MVC) is a popular design pattern for games and websites. It divides code into three sections.

The Model

The model stores data. If there are functions in this section, they’re functions for accessing, manipulating, and transferring that data.

The key is to make sure that the model represents (or “models”) something real. If you’re writing a web server for your school, your model will contain student names, grades, and the files in each student’s computer account. If you’re making an adventure game, your model contains your character’s stats, the game map, and the stats of enemies.

All the data.

The View

The view contains the code for displaying your data. This might mean a bunch of print statements to display text in your console, or it might mean complex mathematics to animate 3D graphics.

This section also contains mechanisms to record user input. When you press a button, move your mouse, or hit the spacebar, the view detects these actions. However, the view doesn’t react. Instead, it passes the user’s choices along to the third and final component of MVC.

The Controller

The controller is the “brain” of the entire operation. This section connects the model and the view, and it’s also in charge of your program’s logic. When the view notices that the user has clicked a button, the controller is notified, and it chooses what to do next: does it reload the webpage, open a portal, send an email? In certain cases, the values of the user’s input is used to update the model.

In other words, the controller is a kind of middle-man, passing information back and forth between the model and the view, and updating each one accordingly.

EXAMPLE

To go over what we’ve learned:

• The model stores data, which it passes to the controller.
• The view displays data and detects user input.
• The controller receives user input, decides what actions to take, and updates the model. It then updates the view to display the new info.

Let’s look at a simple game, like snake. You can play it here.

What data does the “model” contain? You’d need data about the snake: its position, how long it is, how fast it’s moving. You’d also keep data about the size of the map and where the food is currently located. This information stays the same whether we’re using blocky, minimal graphics, or highly-rendered animations.

The “view” is the actual webpage. It includes the colours and the position of each element on the screen. The view also has methods to detect when you press the arrow keys and turn the snake, or click certain buttons.

The “controller” puts it all together. At every tick of the timer, the code moves the snake in a chosen direction. The controller also checks if the snake has collided with a wall or successfully captured its food, updating the model whenever the snake gets longer.

PROS AND CONS

The main benefits of MVC are clarity and extensibility. Because the roles of each section are clearly defined, you don’t have to worry about functions for updating data being buried between functions for displaying cute graphs, or worse, doing both of these things in a single function.

Separating sections also makes it possible to create multiple views and models, and plug them in & out as needed. Your website can have a view for laptops and a view for phone screens. Likewise, you can switch databases in and out as long as the methods for updating and accessing data remain the same. This wouldn’t be possible if your code was all jumbled together. Redesigning your program’s appearance would mean rewriting everything, not just the view.

On the downside, MVC makes programs more complicated. Passing data back and forth is definitely slower than keeping all the data in the same place, and it can be strange to read the code if you’re not familiar with the pattern. This leads to programmers making mistakes while trying to implement MVC — definitely not good!

Learn More

MVC Framework Introduction

https://www.tutorialspoint.com/mvc_framework/mvc_framework_introduction.htm

model-view-controller

https://en.wikipedia.org/wiki/Model-view-controller

Design Patterns & Anti-Patterns

https://kidscodecs.com/design-patterns-anti-patterns/

An explanation of MVC from Codeacademy

https://www.codecademy.com/articles/mvc

Architecture Patterns vs Design Patterns

https://www.oreilly.com/ideas/contrasting-architecture-patterns-with-design-patterns

Elementary Model View Controller video

https://www.youtube.com/watch?v=LiBdzE_DJn4

Catalog of Design Patterns

https://refactoring.guru/design-patterns/catalog