What’s the difference between MVC and OOP?

I received an interesting question during an interview. Until then, I had known of both of these concepts, but I’d never really compared them to one another.

At a high level, MVC (model view controller) and OOP (object orient programming) are both patterns.

Object Orient Programming

Many programming languages contain the idea of an object. These objects contains information and procedures. Objects can be tied to classes, a category or template that makes objects similar or different from one another.

There are four main principals of OOP:

• Abstraction: The process that makes each object different from one another.

• Encapsulation: Classes contain their own attributes and procedures. These aspects aren’t shared by other classes. This is also known as data hiding.

• Inheritance: Some objects can inherit procedures or attributes from other classes.

• Polymorphism: An object’s data type or class means that the programming language will have to process the object differently. For instance, a string is treated differently than an integer in many languages.

Not every programming language is truly OOP. Javascript, for example, doesn’t really have classes, though they can be created.

Model View Controller

Unlike OOP, MVC is what frameworks are built upon.

• Model: The template for each instance of a class.

• View: What the user sees. The client-facing instrumentation of a program.

• Controller: The routing protocols of a program.

Each of these aspects operates in a different capacity to “show” you this webpage. It’s also easy to see these files in action. When I was first learning about MVC, I would build Rails apps to study the concept.

To illustrate, I created an app to simulate a flower shop.

Under app, there’s a directory for models, views, and controllers.

The models contain information about methods and the relationships of each table in the schema.

class Customer < ApplicationRecord
    has_many :orders 
    has_many :flowers, through: :orders 

    validates :name, presence: true 
end

The above code sample represents the customer model. Each time a new customer is created, it follows the methods in the models. This is also where some of the OOP concepts come into play. The models act as templates for the objects they create. This Customer model inherits from the ApplicationRecord class. It also has relationships with the other models, but the other models do not necessarily share the same methods.

This model correlates to the CustomersController.

class CustomersController < ApplicationController

    def index 
        @customers = Customer.all 
    end

    def show 
        @customer = Customer.find(params[:id])
    end

    def new 
        @customer = Customer.new
    end

    def create 
        @customer = Customer.new(customer_params)
        if @customer.valid?
            @customer.save 
            redirect_to @customer
          else
            render :new
        end
    end

    def edit
        @customer = Customer.find(params[:id])
    end

    def update 
        @customer = Customer.find(params[:id])
        redirect_to @customer 
    end

    private 

    def customer_params 
        params.require(:customer).permit(:name)
    end
end

The controller takes care of the routes of our application. Each of the methods relates to a different page a user might see when they access the application. The controller works like the machinery used to change a train track. With each change, a different route is selected and a different set of procedures is applied.

Finally, there’s the views. Each view correlates to the controller methods we saw in the earlier example.

For instance, in the show route, a user will see information about their account.

<h1>Your Account Information</h1>
<%@customer.name%>

Ideally, we would like the information of that particular customer to be displayed. Where is that information held?

It’s in the table.

class CreateCustomers < ActiveRecord::Migration[6.0]
  def change
    create_table :customers do |t|
      t.string :name

      t.timestamps
    end
  end
end

The table is like a spreadsheet of the data (at least, when you’re using a database like SQL). By looking at it this way, it’s even more obvious what role the controller plays.

In order to grab information about that particular customer, it will go through the controller, see this method:

 def show 
        @customer = Customer.find(params[:id])
    end

And use that to pull information from the database to be displayed.

Summary

While both OOP and MVC are concepts, the implementation of them happens in different ways. OOP is the concept that governs how objects (data) is created and managed. MVC is the set of procedures used to display that user to the user.

They’re important concepts, but not every language (or even framework) will necessarily follow them to a T. Think of OOP and MVC as patterns, not rules. If you’re just starting out, there’s a big change you’ll come into contact with these two concepts many, many times.