The idea of object-oriented programming is much wider than the possibilities of PHP due to its specifics, but even in the existing implementation, it gives the programmer unlimited possibilities. The construct PHP construct is a special method of a class (object) that is called every time an instance of the class is created.
The limitation is that PHP is working at the time of page formation. At the moment when the page is updated or another page of the same site is loading, the desired system of objects is formed again from scratch.
Creating an instance of a class
The class description does not have to have a constructor. If you need to prepare the initial values of variables, catch the moment of creating an instance of the class (object), perform certain actions on other objects, then you can not use the PHP class construct syntax and write the corresponding code outside the class methods.
According to the logic of the object-oriented programming style, each class should have a constructor, moreover, you should start the class tree with the most abstract (absolutely empty) ancestor. This is a relic of the past, not a sensible practice.
When a pedigree begins with a meaningful class that has its own data and properties associated with external data (objects), you cannot do without construct construct PHP.
In this example, when creating (PHP construct) an instance of the date class, this function (constructor) will be called. It has a specific name __construct and is called automatically only once when an instance of the class is created.
This class provides a static variable $ iUniqueNo, which in each new instance of such a class will have a unique value. Instances of classes have nothing in common with each other except for the description within the framework of the PHP syntax and the interaction provided by the developer of their methods.
Inheritance of Initialization Logic
Each object must realize its mission, have what it should and do what it should. From such a reasonable point of view, initialization at each level of a pedigree can include initialization in each ancestor called from the descendant level.
In this example, the parent :: keyword allows you to call the constructor of the ancestor from the descendant level. The semantics are simple. First, the ancestor must complete its initialization, then the current instance. The first follows its own logic, the second follows its own.
When each object does its own thing, the overall process looks right and clear. But this rule should not be considered the norm for all systems of objects.
In the very first approximation, the pedigree of the system of objects “food” may have something in common, but the products milk, watermelon, pasta and groats, although they belong to such a system, they look and are described in completely different ways.
The developer must build each system of objects from the scope, and not from how it was once proposed by someone. Each task is unique, the requirement to use parent construct in PHP is not absolute.
Public and private constructors
By default, the constructor is generic and available for use by all descendants. It is not necessary to specify a public function construct, PHP by default treats everything described as general.
How much does it make sense to use the private keyword when describing constructors - the specifics of a task, a feature of the development process, or programmer preferences?
From a conceptual point of view, the genealogy of objects can allow any prohibitions of ancestors in relation to descendants, but it is difficult to say how reasonable this logic is, in any case, in the general context.
Object lifetime
The concept of object-oriented programming is wider than the capabilities of the PHP construct class for the simple reason that the latter exist only at the time of page formation, its re-creation or the creation of another site page.
The participation of AJAX through a JavaScript browser and proper code on the server will help extend the life of objects, but in any case it will be a limited style.
PHP provides the ability to execute a script on the server when the client has "disconnected", and to "allow" the client back to the script that it started earlier, but this is not at all the case when the object-oriented program is implemented in C ++.
In the latter case, it is possible to build a complete system of objects that will exist "forever" while the program is running and working. However, this is the only thing a stationary programming language such as C ++, C #, Pascal & Delphi can boast of. In a dynamic Internet world, everything is built differently, lives faster and achieves more.
From serialization to self-preservation
You can find historical justification for the term "serialization" and the appearance in everyday life of the concept of "magic methods". But everything is much simpler. Exactly the same thing that distinguishes C ++ freedom from C # rigidity, serialization differs from commonplace concepts:
- write an object to a string;
- read an object from a string.
Surrounding what has been said with magic and mythical magical methods is beautiful, sonorous, but little practical. The world of information is interesting primarily because everything that is visible, audible and tangible can be described in simple and consistent text.
Information has always been, is and will be a string of characters. No matter what nature. In the formal constructions of programming languages, the nature of symbols is one - the encoding table.
The idea of turning an object into a string so that, if necessary, you can restore it from this string without losing the essence is a very practical idea.
From self-preservation to self-development
The semantics of the PHP construct constructor are limited within its syntax, but if the constructor is developed from a developed perspective:
- there is a beginning - a completely new instance is being created;
- there is a current state - an existing instance is created.
Limitations of PHP due to the fact that the system of objects on it exists only at the time of page formation, will be removed by themselves.
By creating a system of objects during the formation of the site page, it can be saved. For simplicity, this process does not have to be called serialization, you can limit yourself to saving the current state of things (database, files), and when you need to re-create the same page or create another on the same site, simply restore the current state of things that has already been formed.
In this context, a system of objects is created only once, and in the process of the site’s work, it simply develops. With such a scheme, it is possible to design a system of objects as something that adapts to changing conditions of existence.
A self-preserving system of objects "remembers" the actions of the visitor and the state of the pages, and every time PHP starts, it is not created from scratch, but is restored to its previous state.