Home » Software Development » MVC vs. OOP

About Yegor Bugayenko

Yegor Bugayenko
Yegor Bugayenko is an Oracle certified Java architect, CEO of Zerocracy, author of Elegant Objects book series about object-oriented programing, lead architect and founder of Cactoos, Takes, Rultor and Jcabi, and a big fan of test automation.

MVC vs. OOP

Model-View-Controller (MVC) is an architectural pattern we all are well aware of. It’s a de-facto standard for almost all UI and Web frameworks. It is convenient and easy to use. It is simple and effective. It is a great concept … for a procedural programmer. If your software is object-oriented, you should dislike MVC as much as I do. Here is why.
 
 
 
  
 
 

Hot Shots! (1991) by Jim Abrahams

This is how MVC architecture looks:

Controller is in charge, taking care of the data received from Model and injecting it into View—and this is exactly the problem. The data escapes the Model and becomes “naked”, which is a big problem, as we agreed earlier. OOP is all about encapsulation—data hiding.

MVC architecture does exactly the opposite by exposing the data and hiding behavior. The controller deals with the data directly, making decisions about its purpose and properties, while the objects, which are supposed to know everything about the data and hide it, remain anemic. That is exactly the principle any procedural architecture is built upon; the code is in charge of the data. Take this C++ code, for example:

void print_speed() { // controller
  int s = load_from_engine(); // model
  printf("The speed is %d mph", s); // view
}

The function print_speed() is the controller. It gets the data s from the model load_from_engine() and renders it via the view printf(). Only the controller knows that the data is in miles per hour. The engine returns int without any properties. The controller simply assumed that that data is in mph. If we want to create a similar controller somewhere else, we will have to make a similar assumption again and again. That’s what the “naked data” problem is about, and it leads to serious maintainability issues.

This is an object-oriented alternative to the code above (pseudo-C++):

printf(
  new PrintedSpeed( // view
    new FormattedSpeed( // controller
      new SpeedFromEngine() // model
    )
  )
);

Here, SpeedFromEngine.speed() returns speed in mph, as an integer; FormattedSpeed.speed() returns "%d mph"; and finally, PrintedSpeed.to_str() returns the full text of the message. We can call them “model, view, and controller”, but in reality they are just objects decorating each other. It’s still the same entity—the speed. But it gets more complex and intelligent by being decorated.

We don’t tear the concept of speed apart. The speed is the speed, no matter who works with it and where it is presented. It just gets new behavior from decorators. It grows, but never falls apart.

To summarize, Controller is a pure procedural component in the MVC trio, which turns Model into a passive data holder and View into a passive data renderer. The controller, the holder, the renderer … Is it really OOP?

You may also find these related posts interesting: Encapsulation Covers Up Naked Data; Who Is an Object?; ActiveRecord Is Even Worse Than ORM; Getters/Setters. Evil. Period.; Vertical vs. Horizontal Decomposition of Responsibility;

JavaScript is disabled in your browser, that’s why you can’t see comments under this post.

Reference: MVC vs. OOP from our JCG partner Yegor Bugayenko at the About Programming blog.
(0 rating, 0 votes)
You need to be a registered member to rate this.
1 Comment Views Tweet it!
Do you want to know how to develop your skillset to become a Java Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. JPA Mini Book
2. JVM Troubleshooting Guide
3. JUnit Tutorial for Unit Testing
4. Java Annotations Tutorial
5. Java Interview Questions
6. Spring Interview Questions
7. Android UI Design
and many more ....
I agree to the Terms and Privacy Policy
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Anton
Anton
4 years ago

Surprised to see this article. MVC has been taking a back seat to component methodology for a while now as far as web frameworks go – since 2014 when virtual dom started gaining momentum.

The anemic model is a result of service oriented architecture, where logic isn’t serializable. Id consider an application to be overengineered that it adds a layer of code to take anemic model data from a lower tier into a rich model just to turn around and put that into a new anemic model for the upper tier.