What's wrong with doing this in php?

The reason why I asked this question is actually because I read this answer on Zhihu:

What are the common low-level errors in PHP programming?

http://www.zhihu.com/question...

The wrong approach mentioned:
Using Class as a namespace, method is just a function of Class

What’s wrong with doing this?

Reply content:

The reason why I asked this question is actually because I read this answer on Zhihu:

What are the common low-level errors in PHP programming?

http://www.zhihu.com/question...

The wrong approach mentioned:
Using Class as a namespace, method is just a function of Class

What’s wrong with doing this?

Using procedural structured programming is "ideological solidification"? I think treating "object-oriented" as a universal "one-size-fits-all" is "eight-legged essay-like ideological solidification", and even proposed that be completely object-oriented This kind of "one size fits all extreme" programming requirements. I think the biggest benefit of object thinking is encapsulation. It can encapsulate related functions and provide them for others to call. If there is a naming conflict, just change the class name. If you don't use classes, there will be naming conflicts. Sometimes you need to modify the prefixes of multiple functions. So there is nothing wrong with using classes as namespaces.

Let’s look at PHP itself. The functions provided by PHP include two types of encapsulation: function-based and class-based encapsulation. Function-based encapsulation includes commonly used string operation functions and array operation functions, etc., and class-based encapsulation includes SPL libraries, etc. You will Is object-oriented necessarily more advanced and convenient than procedural programming? I can't see it. If you are really so keen on object-oriented, shouldn't you learn Java where all libraries are based on class encapsulation and are "completely object-oriented"?

Java master Wang Yin looks at object-oriented programming:

"Object thinking" as a way of data access has certain benefits. However, "object-oriented" (with the addition of the word "oriented") is just a rambling, far-fetched, and excessive use of this originally good idea. Many object-oriented languages ​​claim that "everything is an object", put all functions into so-called objects, called "methods", and call ordinary functions "static methods". In fact, only very rarely when abstraction is needed, do you need to use "methods" that are embedded in the object and closely integrated with the data. Other times, you actually just want to express transformation operations between data. These can be expressed using ordinary functions, and it is simpler and more direct to do so. Putting all functions into objects is putting the cart before the horse, because functions themselves do not belong to objects, they are just transformation operations on objects. Most functions are independent of objects and cannot be called "methods". Forcing all functions into objects that they do not originally belong to and treating them all as "methods" leads to overly complex object-oriented code logic. It's a very simple idea, but you have to go through many detours to express it clearly. Many people still don’t know that many of the advantages of the “object-oriented language” they use are inherited from procedural languages. Most object-oriented languages ​​lack a correct mechanism for implementing first-class functions. The Java language is an extreme, it does not allow functions to be passed as data at all. You need to encapsulate all the functions into classes and call them "methods", but like I said, this is kidnapping. The lack of first-class functions is the main reason why there are so many "design patterns" in Java. Once you have first-class functions, you won't need most of these design patterns.

Personal opinion only:

The biggest problem is the solidification of ideas. I can’t get out of the process, and I can’t understand what object-oriented programming really changes. What are the real advantages of object-oriented programming, let alone interface-oriented programming.