OOP Overkill
Tags: oop, classes, objects, encapsulation
Published: 2018-06-27 12:21:29

---
title: OOP Overkill
published: true
cover_image: https://thepracticaldev.s3.amazonaws.com/i/av9nu109ne3fcqvkolsb.jpg
description: 
tags: OOP, classes, objects, encapsulation
---

Hi there,

I've had for years a dillema that i just couldn't figure out. At some point in time i had to search for frameworks and CMSs, so i've taken a look at most major PHP frameworks and some C++ as well (not implying that they are related). I've also taken a peek at various open source projects out there, written in various languages, just to see what they're made of.

I've come to see that there's a trend that i like to call "OOP Overkill"; that is programmers tend to throw lots and lots of classes in their source code, everywhere, for every possible reason. And they also tend to create complex hierarchical structures of base classes : derived clases, and so on, alot of times for no apparent reason. I remember the first time i saw this, it was in MFC (Microsoft Foundation Classes), where for every possible window that you wanted to use, it automatically created a class for you. In web frameworks, this translates to at least a class being made for every web page that the application needs to deliver. OpenCart, for instance, uses 3 classes for each web page: one for model layer, one for controller and one for view. And that is on top of a plethora of other system classes that handle core functionalities.

There are even entire languages, like Java and C#, that force this design principle on you, making the entire application one big class (well ok, not so big, but still, instead of having only a main() function to start with, you get your application encapsulated in a class and there's nothing you can do about it).
And even if the language itself doesn't force this, there are lots of programmers who are verry eager to create an application class from the first lines of code and then just quickly instantiate a single object, spreading the logic all over tens of other files, inside member functions (methods) that you litteraly have to chase if you need to do something or to understand how everything works.

Personally, i don't see OOP as a "look, this is how everything should be done and look like". In my opinion, it's more like "look, this is a powerful tool; use it to give life to abstract ideas, encapsulating data and operations in a single object, whenever you need and it makes sense to have such thing". Therefore, as with any other tool, it's your freedom to use it or not.

In my ~15 years of doing all sorts of programs (desktop, web applications, etc.), i've never ever felt the need to take this approach. I've also never ever felt the need to use class inheritance, abstract classes, interfaces or anything the like. And i've taken quite complex projects but still, in languages like PHP, where you have arrays which are verry powerful and versatile, working with data cand be done at a simple level, without the need of complex encapsulation.

But, maybe there's something i'm missing. So my question is: what are the objective benefits of choosing such a design, encapsulating everything, including the application itself, into classes over classes over classes ? Is there, maybe, a security reason i'm not aware of ?

Thanks alot !
Cheers :)