When is it time to use OOP?

Question

PHP

Good afternoon.
For the last 5 years I have been developing web applications (mainly for small businesses). I work alone and do not involve contractors.
The bundle is as follows: PHP (sometimes NodeJS) + MySQL (sometimes Postgres and SQLite) + frontend (I will not describe in detail).
Technology debugged:

• The client (browser) calls the required RPC API procedure (via xmlHTTPRequest), while passing the authorization token
  
• The procedure processes the incoming parameters, accesses the Database if necessary (via the PDO class), and returns a response in JSON to the client.
  

From project to project I can copy procedures so as not to write again.
Recently I read an article, the essence of which was this: if you do not write in the OOP style, you are a sucker.
Not that it hurt, but it became interesting why?
In this case, my APIs should no longer access the database themselves, but work with instances of object classes.
Who can explain the specific benefits of changing the approach?
At what point (starting from what size of the project) should you switch to OOP?

Answer 1

Don't beat yourself up. If everything works and everything suits you, then why change something?
The benefits of OOP are manifested with the support of the project.
Do you support your projects? Are you developing them? At what point did it become difficult for you to support the project?
Are there many abstractions in the project?
How do you solve the problem of adding new abstractions to a project?
If these questions are not about you, then you do not need OOP.

Answer 2

OOP, as you know, simplifies the development of programs consisting of interacting state-changing components. This is not enough on the web, and therefore it is possible to be a successful webist and not know OOP. OOP gives a double win.
1) Encapsulation - we hide the internal state, allowing it to be changed with special “levers” brought out to the outside.
• Close work with communication protocols (eg mail).
• Support for something with a changing state (this is not enough on the web - maybe some kind of automatic layout?)
2) Abstraction and polymorphism - in general, support for different things under a common facade.
• Uncertainty in technology - maybe MySQL, maybe SqLite. Then we create an abstract class "DB" and inherit MySQL and SqLite from it.
• Some stuff from the subject area. We are writing a game - it is convenient to keep the characters of the game like this. Although it is possible to write a multiplayer game entirely in PHP - I'm not sure about that.
• Well, I don't know where else. Desktop / mobile version, or what?

Answer 3

Now it was time for him to use OOP:
www.gamedev.ru/projects/forum/?id=160897 (links to download the sources in the first post, there are also code fragments in other posts).
Are you not so bad?

Answer 4

Do you want to understand why OOP? Use a simple framework (for example, Laravel 5). Explore the docks, etc. make a simple website. And then I think you will understand how charming this paradigm is.

Answer 5

No one has made a single weighty argument in favor of OOP in PHP. Everything rests on “buddy, eh, try it and you will understand how cool it is.”
If we create a GUI application that runs until the user stops it, then OOP really makes sense there, at least in the process of interface programming. But in the case of PHP, the program works for a fraction of a second (while processing the request) and the same interface does not need to be programmed. The goals of a PHP program are: to be understandable, to be fast. And both of these cases are not about OOP.
To be understandable, a program needs simple, friendly logic (this is the most important abstraction layer that gets overlooked), unduplicated code, and documentation. At the very least, it doesn't need extra syntax to be fast.
Analyzing the same Laravel, I see a couple of good things that are more logical to implement in functions and a bunch of code for the sake of code.
Here is an example https://laravel.ru/docs/v3/database/fluent
$users = DB::table('users')->get();
But nothing prevents us from writing a logically polymorphic function q():
$users = q("users");
The same function can accept a SQL query or a more complex over-SQL construct, but at the same time more understandable than a method chain. Someone may object that the function will be tied to one type of database, but I remind you that, depending on the type of database used, nothing prevents us from loading the necessary file with the corresponding function implementation, for example, mysql.db.php postgresql. db.php
If the logic of the procedural code is balanced, if there are no duplicates of the code, if there is documentation, then the procedural code will be better than any OOP code by two criteria: accessibility for understanding, speed of work. Considering that OOP code also requires balancing and documentation, the benefits of procedural code become absolute.

Answer 6

at any time, oops it's convenient, allows you to use a lot of the right ones! tools, allows you to write less code

Answer 7

read Zandstra 4th ed. Somewhere from Chapter 6 Part 2.

Answer 8

Something even xs, what to answer ... OOP is a fundamentally different development paradigm than a procedural style. In general, your case is quite interesting when you are satisfied with the procedural style for 5 years.
In any case, it is better not to implement OOP on current OOP projects (you will get problems). But something new can be started.

Answer 9

I work in much the same way as you - my own framework, everything is debugged, etc. I've been working in OOP for several years, trying to figure out where to apply it. Where applied, the complexity increased sharply.
The only place where so far OOP seemed logical, understandable and obligatory for me is team development or module development for a ready-made someone else's project. In this case, I'm just supplying my class or set of classes in my namespace that solves the business problem, perhaps providing an API.

Answer 10

Learn to ask the right questions. Regarding the web, this question should sound like this: At what point is it time to stop using OOP?
To understand this difficult moment, try to file several sites on OOP frameworks. You can have several, or you can have one good one. It doesn't matter. At some point, you will catch this fine line.

Answer 11

> if you don't write in OOP style - you sucker.
This is already outdated, now in fashion is the rejection of OOP! Look at go - procedural programming + interfaces.
Look at Scala - functional approaches in the Java ecosystem (here also Clojure and Kotlin).
The frontend is full of functionality: ClojureScript, Elm, Purescript. The same fashionable now React+Redux.
So feel free to forget about OOP and start writing in Clojure + ClojureScript!

Answer 12

Personally, I have a complete understanding of why OOP is needed only when I read the book "Perfect Code".
Read it, it's a must-have book for any programmer who writes in OOP and (suddenly) without. There even is such section: "Reasonable reasons for using classes" where everything is chewed in detail. With examples.
If you fix it with a book by Matt Zandrst, then the understanding will be even deeper.

Answer 13

iantonov.me/page/pishem-sobstvennyj-mvc-frejmvork-...
read, study, do, you will understand in the process.

Answer 14

Recently I read an article, the essence of which was this: if you do not write in the OOP style, you are a sucker.
Not that it hurt, but it became interesting why?

When it comes to business logic (IMHO, this is at least 90% of all code existing in the world), then this is so.
In some other areas it is not always possible or not needed.