OOP without "O"

I hope the materials published in this article do not seem too obvious or an attempt to insult the feelings of "believers", and even more so no one will take the title of the article too literally as "oriented programming." In any case, this article is an attempt to share personal experience, and not to promote their point of view.

A bit of background: I am a conservative person, I accept all the changes "in hostility", but if the advantages are obvious, then by cooling my ardor I try to get used to the "innovation". So it was with OOP when in the process of mastering PHP I ran into it. First, I perceived classes and the creation of objects as a pure overhead (and not to say that it was a mistake), but in the process of acquaintance, the “structured” and “order” that gave the PLO made me a religious fanatic of the PLO (and MVC, but now is not about this).

At about the same time, I changed jobs and got into the development team where the company's multifunctional portal was written in pure PHP (without the use of frameworks), and each gate could. Of course, there were high-level developers there, but the time to refactor the existing code was very small, most of the time was spent on expanding the functional, and all the more there could be no question of changing the structure and rewriting everything from scratch. There were also examples of “bad OOP”, for example, in the client code (some kind of controller, if we draw an analogy with MVC), at the very beginning all objects were created that would be used in the code (they also included them beforehand, without any hope of an autoloader) and not least, some semblance of the delegation pattern was applied to them: a mysqli object was created and assigned to the sql property of each object. You can only imagine how many unnecessary actions to empty and how much memory overruns occur.

Here is my basic example:

class A{ public function __construct(){ } public function doSomething(){ } public static function someStatic(){ } } class B{ public function __construct(){ } public function doSomething(){ } public static function someStatic(){ } } echo((memory_get_usage()/1024)."Kb"); //: 211.90625Kb 

These measurements are only to estimate the weight of the “empty page”, that is, here we have not yet created any objects and have not used any methods from the class.

Now let's see what it will cost us to create such “useless” objects and call their methods:

 $a=new A; $a->doSomething(); $b=new B; $b->doSomething(); echo((memory_get_usage()/1024)."Kb"); //: 214.15625Kb 

As you can see, the difference is not impressive, but it is provided that both the object and the method essentially do nothing at all. As you know, PHP has static methods and properties that belong to a class, in contrast to the usual methods and properties that belong to an object of this class. Our classes contain just such methods (coincidence? - I don’t think), their functionality is exactly the same as the usual methods of this class, so in fact we can do the same actions bypassing class creation:

 A::someStatic(); B::someStatic(); echo((memory_get_usage()/1024)."Kb"); //: 212.6171875Kb 

Perhaps the comparison on the "ultra-low" numbers does not give a complete picture, but this is the very overhead from which you can refuse. I don’t like to create objects, and this is what this article is about, I try to make maximum use of static methods and properties. The reason is not love to work with the object (when transferred to another method), because I have a phobia that he is not who he claims to be, of course you can check him for belonging to one or another class through the instanceof, but so that there are no unforeseen results are better to check its contents, which may turn out to be a chore, and it is easier to assemble the necessary structure during the execution of the script (further please treat with understanding) using the advantages of a structured class system, but not creating objects in the client code, essentially in pseudo procedural style. But back to the code.

If you are concerned about the implementation of the constructor functional, then this is implemented through self:

 class A{ public $prop; public function __construct(){ $this->prop='test'; } public function doSomething(){ } public static function someStatic(){ return new self(); } } 

 $a=new A(); echo $a->prop; //test echo((memory_get_usage()/1024)."Kb"); //: 211.9140625Kb 

 echo A::someStatic()->prop; //test echo((memory_get_usage()/1024)."Kb"); //: 211.5703125Kb 

The most attentive and resourceful of course will offer something like (and they will be right):
')

 echo ((new A())->prop); //test echo((memory_get_usage()/1024)."Kb"); //: 211.53125Kb 

But this is only because execution examples are too exaggerated, and some implementation in such a scheme can be achieved only if the method returns this object ($ this).

This whole line of thought is only to explain that it is not necessary to create objects in OOP, and you can do without them saving memory (as in principle without any extra assignments), unless of course this is justified by the application architecture, or pattern, and of course you should not be given in the extreme, if you need an object - create an object, sometimes you can't do without it. But if the result of some action is an object, then why not immediately start working with it?