OOP Overkill

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 :)

Comments

[Aleksi Kauppila]

I've been lately viewing it as having a gathering of different experts. I need to deliver some Mail. Then i need to request a Mailman to deliver(Mail mail). That expert may check that the Mail has all the information it needs to be sent. I don't do that checking, i just do my best to provide all the information that the Mailman can do it's job.

I don't need to know how the mail is delivered, it's not my expertise. It's actually nobody else's problem to know how to deliver mail.

A lot of folks dread Manager classes in code. Also in real life: i should know best HOW to do the thing i'm requested. I have those properties in me to do the job.

[eerk]

"I've never ever felt the need to take this approach"

That makes sense, because that need doesn't drop out of the sky while you are busy typing functional or procedural code. You're already comfortable and effective with a technique, so why change it?

You'll first have to spend some time stepping out of your comfort zone, learning how OOP works and how you can use OOP patterns to build something. It will take more time to achieve the same stuff at first, but sooner or later you'll have a few "a-haaaaa" moments.

OOP is not just about classes, but also about achieving a common way to structure code, making it easier to work in a team or work on someone else's code.

Have you looked at the MDN documentation for the DOM?. I think this perfectly illustrates a good use case for OOP inheritance.

MouseEvent is an Event that has some extra properties that only apply to events triggered by using the Mouse.

HTMLCanvasElement is an HTMLElement that has extra properties that only count for canvas elements.

[Riccardo Bernardini]

I agree with you. Definitively I do not like the "everything is an object" approach or code with a hierarchy of classes with a very fine resolution. I remember a library that had something like "abstract socket," "abstract TCP socket," "socket that eats bytes", ... "RTP socket" and so on. Honestly, a mess.

I program in Ada (that allows OOP, but not forces it on you) and my choice if defining a class (a "tagged type" in Ada jargon) or a normal type is if I expect to need hereditary or polymorphism or if I need to "factorize" some common code. For example, in a program that reads different formats it can make sense to have an "abstract parser" that defines the interface that an "input parser" must have and then for every format there is a parser handling it. This makes much simpler to add new parsers.

[Ahsan Ashraf]

Clean code much?

[Ciel]

Look up a design anti-pattern called the "God Object" as well. You want as many parts of your application as far away from each other as possible.

[Joaquim Ley]

You're trolling, right?

[Rafael Chaves]

Classes (or structure types, at a lesser degree) provide a language supported way for you to model your problem domain. What is a Customer? What is an Order? What are the possible states of an order? What actions can you perform on them? Go to those classes and read it up.

There is one place with the authority of defining each of those concepts. All places in the application that use those classes need to conform to it.

If you use associative arrays or dynamic objects, this central, authoritative, source of truth disappears, and now you need to carefully read all code dealing with some object to figure out what they do with it (which 'fields' they create, which kinds of values they assign, etc).

[proddi]

I can absolutely understand the author. In my career i saw a lot of oop code like:

report = ReportBuilder(a, b, c)
report.do_something()
result = report.get_results()

To me this is using OOP without using the brain. If it behaves like a function .. maybe it is a function. Besides this most of the implementations deserves a rant because this pattern guides the dev to initialize/load everything into memory!

My main question is the same as well. Why coders sometime choose the more complicated way?

• Do they don't know/see the easier way (because of experience)?
• Do they get enforces indirectly by (company/project) policies?
• Do i am just wrong?

[eerk]

This really depends on what's inside ReportBuilder. Maybe it's a class that has to collect tons of data and do complex analysis.

In that case, it's super easy that you can use all that functionality in just 3 lines of code.

Also, don't forget that you are already using built-in classes every day! From using arrays to typing console.log(), all that functionality has to be programmed somewhere, and that's mostly in a class file.

[dallgoot]

You brought a hot topic here my friend :)
I start with the basics :

• OOP is useful, very
• OOP si very often wrongly used

The mistake that can be seen very often is people thinking that methods calls are free or that every bit of their code needs a state.
Many classes should have their methods as static ones.
Many methods, especially from unexperienced programmers are useless or add performance or complexity issues just because they think OOP is the only way to go.
As examples :

public isMainSite():bool
{
   return IS_MAIN_SITE;
}

completely useless and a perf drop for no other reason than "i'm doing OOP"

or

private $myVar;
public function getMyVar()
{
    return $this->myVar;
}
public function setMyVar($value)
{
    $this->myVar = $value;
}

again: completely useless : if your setter and getter that do nothing then the property IS public by its use.
You can access class prop a lot more efficiently directly than through methods call.
Again something that few people think about: they learned "a way' to OOP and don't question it anymore.
So , OOP is useful, no douvt on this BUT is very OFTEN misused.

[Damien McAlear]

Actually, your second example isn't useless.

For sake of argument, your getter/setter is used in multiple locations throughout your application.

You've changed something/discovered a bug/etc. with that variable within your class when it's set to specific values. You can safely put in some input validation into your setter to only allow correct input values (you could even make it a boolean/return a success condition).

If you had direct access to the variable, not only would you have to create some sort of validation after the fact. You'd also have to change all references to the variable to now use your getters/setters.

This might be fine on smaller projects but in a large project or some sort of Framework/Library could cause lots of extra work.

In short, it's better to future proof in that case.

[dallgoot]

i got to disagree on the principes of future proof.
That is a conception key point :

• or this variable needs validation and so it Requires Setter/Getter
• or (as in the example I wrote) it doesn't need validation and so setter/getter are just one useless layer of abstraction.

The point you make that maybe in the future you'll need validation is very interesting: it confirms another OOP situations where developpers overlook properties roles and visibility.
But that is not an OOP requirement or practice it's a conception mistake that needs to be fixed.
My point is that many devs think setting private AND writing setter/getter is "the way to go" in all situations, that's wrong on many occasions.
Visibility/validation is an important part BUT of the conception phase.
I don't even mention security 'cause if it was not thought in conception something's wrong.

[Jose Luis Romero]

15 years coding without use OOP hahahah, you code suck in every possible way.. and you just now are interested in known it benefits?
There is a simple explanation, PHP programmer, I have had the bad luck to have team up with your kind (with similar age like you), it took me years and even today when I have to review their code I know they don't get it
I don't even dare to ask your opinion about AOP (scary face)

[adriannull]

Right, well good for you that you think yourself better than me and most others. For your information i'm not strictly a PHP programmer, i know several languages and i started with C/C++, so i'm familiar with a more strict language. Anyhow, i've got applications running 24/7, exposed to internet, and never had a problem because of my coding choices.
And btw, my post was not strictly about PHP, in fact i actually wrote it's a general trend i see.
You basically wasted your time writing a completely non-constructive reply.