Can this be rewritten in OOP? And how about all this can be distributed by class?

Question

PHP

I have a training project (message board) and now I'm redesigning the code structure from procedural to functional, as a result, I get approximately the following groups of functions:
function_items.php - everything related to writing to the database and displaying declarations and operations with them (for example add to favorites)
function_users.php - everything related to users, registration, login, editing personal information, etc.
function_images.php - all operations with pictures, resizing, cropping, etc.
And so on, I break it into groups of functions.
So, in terms of learning, you definitely need to master OOP (at least the basics, but not on examples of cars and planes, but on live code) and I think how can this be converted into classes now?
That is, for example, instead of the function_items.php file, I will have Class Items and everything in this file will be in one class, right?
But it seems to me that my code is not yet complex enough to be turned into classes (classes are just a way of organizing code, as far as I understand).
That is, Encapsulation, Inheritance and Polymorphism are of no use to me here yet, is there simply no such need, or is there anyway? I ask you to help me understand whether OOP is needed in simple projects or should it be left as separate functions?

Answer 1

Try to pull this functionality on a simple framework like laravel - yes, it's not perfect, but I think it's better to start doing at least somehow, and then gradually figure out how to write OOP beautifully.
Items, users, images - can become model classes, where their properties and methods for getting/writing them are described.
From function_images, you can write a module (relatively speaking, a daddy with a set of service classes), where the resizing logic will be described separately, the cropping logic separately, etc.

Answer 2

classes are just a way of organizing code as far as I understand

no. you don't get it right at all.
I already advised you to read Fowler, did you do it? You ask the same questions, which, in principle, no one can answer you - this is the topic of a whole book. All advice here will only be a disservice.
You have two ways:
1. Take a framework and write from scratch
2. Read a book and reinvent the wheel, rewriting your noodles to oo-style. You will pump, but you will spend a lot of time, which will be an extremely dubious action in terms of profit.

Answer 3

I really liked the way Aleksey Pastushenko explained it to me
. So I understood what he said:
Look, the computer will still execute machine code under the hood, procedurals - the function arguments into it and let's go, or more precisely - machine code, logical AND / OR, but to think since the car is more problems than advantages, although for general development you can learn about diodes, transistors, pn junctions, and wherever you fly away. But if you try to draw on the board with squares what clings to what, then you will get a million squares, because each function will be a separate square.
OOP can be understood as an attempt to draw a map for some island. This is how ports will be depicted, like this - lighthouses. this is how the woods will be. That is, in the end, the program will work on the procedural. But in order to explain it and find the code that messes up in the event of a breakdown, we draw a map and write documentation for ourselves on it in order to remember that such and such a square does something for us and therefore it messes up. It is important to understand (it took me a lot of time until I stuck it) - that we do not "write in OOP", we rewrite in OOP. When a functional is needed, we write it on the basis of the functions that we put in a folder. And when it becomes necessary to keep track of this - who is where what at what moment and please with the ability to configure from the admin panel - we rewrite it to oop.
In reality - some function mows. But when there is a certain object where it lies, it is easier for us to find the "guilty" (module in the code) and fix it.
Of course, there are other benefits to OOP and its use. For example - to move away from the code that is hard-coded into the file and the ability to replace the whole logic by slipping a new class with the same functions, but in a different way. That is, you do not rewrite all the "if-then", you throw a whole piece at the input, which works the same way, but in its own way.
A separate feature is predictability, if two objects come into the function that must somehow interact with each other - then the first thing to do is to check - otherwise it came at all? In the case of OOP, at least one of these objects will be the main one and it does not need to be checked (it will be $this). Or it will be the third object, in which you will sew the check of these two as if it were a simple function. but the code of the function itself will be cleaner, because the checks turned out to be in other places, but here one action is performed
Otherwise, OOP is code complexity that is worth it. But if you need to quickly link two sites through one script, then trying to draw a map of this connection will eat you up for a week. And to write a function that does this will take about 10 minutes. Therefore, you need to do it quickly - forget it. You need predictability, logging, understanding what is happening where, the history of changes, or what is the most nuclear thing - a rollback in the reverse order from how it was done - you will have to draw a map. Or die on the project

Answer 4

for example, instead of the function_items.php file, there will be Class Items and everything in this file will be in one class, right?

No, not at all, but for starters, you can try it that way. Then take any popular framework and try it in it, at the same time study how the framework implements certain things.
But this is when you know procedural programming well.