TL; DR-Kind of

Is not totally wrong, but it is a bit.

Informally we can say that it is mixed even, but almost all so-called object-oriented languages do the same. The bulk of the code is procedural (or more precisely, imperative). Object orientation goes to another level, more in code organization. It acts more on the data structure and where it will put the algorithms than on the algorithms themselves, which are imperative.

Some they say that OOP is not even a complete paradigm .

In the PHP documentation itself there are several examples of writing the same code with procedural mode and OOP mode. We can accept this definition, but strictly that is not quite OOP. PHP is a language that does not usually follow the correct definitions very well.

Deep down what they're saying there is that you can choose between: 1) passing an object as a parameter to a method; or 2) using a syntax where the method is invoked by the object. What in practice gives in the same under the cloths. In the latter case the method will only have an extra parameter called $this that is hidden. You're just switching the place parameter.

This has some advantage with tools (IDE for example) that can help encode and analyze data already knowing what it is. Other than that, there are no real advantages. Individually there may be some secondary advantage that was best solved in the case of syntax that it highlights the object, but it was something Additional that they took advantage of and solved when they were creating this extra layer. There may be a downside to generating one more layer.

Syntax mixing doesn't cause problems, at least it shouldn't. No paradigms either. The mixture is always good if it solves the problem better, Purism is dogmatic, it is to force something by taste, and not by necessity.

What is OOP?

But using this syntax cannot be considered programming object-oriented. At most, the one who created these classes is the one who programmed object-oriented, not the one who consumed it. Even this is complicated to say because the use of classes does not define that you are programming object-oriented. This paradigm does not even require the presence of classes.

OOP is something much more complex, and basically most programmers have no idea how to program in this way. This includes those who say they Program object-oriented and actually don't, or do all wrong shape. This is explained by the Dunning Kruger effect .

OOP is a methodology to better organize the code and promote its reuse in a specific form.

Not everyone agrees with all the definitions, including the author of the term says that the definitions they usually use are wrong. Although the use of OOP somehow predates the use of the term.

One of the most accepted forms says that OOP occurs when there is inheritance, polymorphism and tunnel. Abstraction and other concepts are often included in some definitions, but these three achieve more consensus.

Most programmers who claim to use OOP do not use or do not know how to properly use the fundamental concepts. So can we say that this person is actually using OOP?

In general they just create classes, which can meet the encapsulation if you do it right. But this is possible to do in any paradigm in one way or another. In the background, when people do this they are programming in the modular paradigm .

In this question (read mainly the part of OOP, it is important to understand) I even say that one of the things that drove programming the most is modularization, and one of the ways to modularize is to encapsulate. This is not unique to OOP. In fact it is something very important.

What is OOP good for?

Precisely because of the inheritance OOP is a hand in the wheel to represent hierarchies and complex relationships between objects. Great for GUIs and some types of games(and other types of application, of course, I will not name everything). But it is not so good for all problems.

OOP really helps a lot to organize large codebases handled by large teams. But OOP has a cost too.

In scenarios where hierarchies are not so important, relationships are not so complex and development is done individually or by very small team, or at least the application is developed in a very fragmented way (natural modularization, typical of PHP applications, since they are scripts), oop, in fact, is not that useful.

And it is even less so when the person does not have a deep understanding of what he is doing. And what we see right here on this site is that people make a lot of mistakes, some grotesque. I make mistakes, even having studied the subject a lot, it is not easy to get right with this paradigm, and it needs to be sure to take advantage of it well, it is not easy to correct later if done wrong at the beginning, although some people believe otherwise (if refactoring solved so well then doing procedural would not be a problem either).

OOP bureaucratizes development. Whether this is good or bad depends on each case and I'm not going to nail down a position.

SOpt itself uses a so-called Object-Oriented Language (although it's a lie to classify C# like that), and its engineers, some of the best of the world, they consciously chose not to use this paradigm for their construction, did not follow folklore, and benefited greatly from it. If this project, which is not at all simple, got better without OOP, why do you think that your simplest web project will benefit from it?

PHP is Object Oriented?

PHP is was a language of script, it's it was an unceremonious language, she shines in it, if not use so much cocksucker they put then.

It executes small snippets of code at a time and they die. These scripts do not last in memory, do not load everything that the application will do, executions are more watertight.

It is much easier to manage this type of code than in a monolithic ERP system , for example.

PHP does a modularization naturally, you use only what you need for that momentary context. You include what you want extremely easily, with nothing of OOP.

PHP is not object-oriented. It is originally imperative / procedural and more recently has additionally adopted OO concepts.

These language extensions for manipulating OOP are great for turning PHP into a general purpose language, but they help very little in the domain where it succeeds, the web.

These extensions make it easy to use OOP, but it was already possible before. Since people don't understand what OOP is, they thought it wouldn't work. To tools only became more obvious.

In fact PHP is one of the easiest languages to adopt OOP even before there is specific syntax for this. All class system, inheritance, polymorphism, etc. PHP was developed on top of the associative arrays (I'm not saying it uses exactly the same arrays of the language, as JavaScript does, it's just something very similar) and it's not difficult to simulate all OO concepts using this engine (it has naive example in this question ). It just did not have the most convenient syntax and already well recognized in other traditional languages that implement classes.

PHP benefits from OOP?

I'm one of the few people who ever used PHP for a non-web application, where the whole code ran together for hours, so the code was more "together". And even in this case I did not miss anything object-oriented, imagine in ephemeral codes that is the typical case of applications web.

Most PHP codes that use classes that I see out there would not need to be written this way and would have no harm using pure procedural, as long as done the right way. Programming right is necessary in any paradigm.

Many say that this is more organized. I even agree that OOP can help organize more code for those who can't organize otherwise. I understand that cake recipes in OOP are often well organized and the recipes that do not use OOP are often more disorganized, not least because they were made at a time when people did not master what they were doing so much, but only helps if the person is a recipe follower.

If the programmer will create programs on their own, he will have to learn to do it right, and can do it organized in both paradigms, in most scenarios.

To learn more.

Design Standards and frameworks

The patterns of famous, general and most useful design and architectures-type MVC - can be very well applied in oop or procedural.

Many also famous design patterns only work for oop . But they exist to solve the problems that OOP started imposing (additional information in the comments by rray). The abuse of these specific standards has already become a meme.

Others exist because language is static. Dynamic languages, such as PHP, are much more flexible and they require fewer "artificial" design standards. They want to "end" this too (I even like static language, but PHP is what it is because it is dynamic).

Principles have been created to help people use OOP the right way, but most are unaware of them or do not know when to use them and when to leave them out.

All this adds complexity to the software. When it needs it, great, this complexity helps software that needs to be complex be easier to give maintenance. If you didn't need it, it's just a complication.

I agree that OOP helped create the current frameworks that are so successful. In fact this paradigm helps this type of software. I even question their use a little. Not that it has no advantage, they just don't solve everything. And it is common for people to adopt them because they do not know how to do things right, the reason is wrong.

But in more common codes I see few advantages in its use.

OOP no solve everything

Contrary to what some people believe, OOP is full of defects, well filled, and does not solve all problems. The question is to know when it has more advantages than disadvantages, and choose its use consciously, and not because it has heard (heard from someone who is passionate about the methodology and often makes money by disseminating it, heard that it is good for you and will solve all your problems).

No one has ever presented evidence, or even empirical evidence, that OOP gives more productivity than other paradigms. On the contrary, there is at least one study showing that there are no gains. Another showing that languages do not fundamentally benefit from this paradigm.

But the analysis that I like the most is Paul Graham when he defines the mediocrity as a determining factor for the success of the paradigm.

OOP does not reproduce the real world like some preach.

Note Well that I'm not saying that OOP is crap that shouldn't be used. Some people tend to see only this part of what I say and not the weighting, not least because they don't weigh the use. They think, " you're either a friend of the OOP or you're an enemy." I use OOP where it needs to.

There is a widespread problem of understanding what is computing and the scientific process as a whole. Then the person reads a book that gives a vision, buys this vision and passes on repeating it without knowing it what you're talking about. And look, I hate academicisms. And the best programmers I know are not trained (this has changed a bit).

There is an article that gathers several fundamental criticisms about the use of oop.

Conclusion

I made several simplifications here. The intention is not to write a thesis, it is to alert and try to make the person reflect and look for more information, even asking new more specific questions, even questioning what I said, so other people can write and give a plural view. It is bad when one blindly accepts a person's vision, even if it is my vision. Be wary of her, too. Be proactive, just do not be stubborn, only you lose (if the people who hire you, they lose by table).

Use both. Learn what has an advantage in each and enjoy the advantages. Avoid the golden hammer .