PHP and OOP. Combining \ "non-interchangeable \" ...

Object-oriented programming is like a lifestyle. This is not just the use of constructions of type class or interface — it is a way of thinking, when any program essence is not just a set of instructions, but is a “living” being ...

I think to remind what OOP is, in the framework of this article, would be superfluous, so I will go straight to the issue.

Developers who came to PHP from other programming languages ​​and encountered in it (in PHP, hereinafter I will mean PHP5 - note ) with classes, are perplexed about how they can be used at all. And all due to the fact that the lifetime of the script on PHP is much less than that of the application software and makes up only one cycle of work, while the application software can live and interact with its components for much longer. As a result, the world is the code in which classes implement only the namespaces that are absent in PHP.

class A {
public static function b() {}

public static function c() {}

public static function d() {}
}


Yes - even this approach has a lot of advantages. For example, we were able to isolate functions related to the same data area into a wrapper class, which reduced the likelihood of conflicts of function names in the code, as well as the readability of the code and tracking of the behavior of functions becomes more transparent:
')

User::register($name, $pwd);
//... a lot of code ...
System::Log($message, $code);


each line of this example speaks for itself and does not require additional comments, which is undoubtedly a plus.

But let's take a look at OOP not just as a programming paradigm with basic features already bored: inheritance, encapsulation, and polymorphism, but look at it as the world around us. What do objects tell us, what is around? Take for example my glasses. What can you say about them? You can measure their weight and size, color and density - these will be the properties of the “glasses” class, but by this they can still break and refract the light passing through the lenses - and these are already methods. We cannot drink tea from glasses, just like measuring the speed of glasses. What does this mean? The class "glasses" has a certain scope of application and possibilities for interaction. We can do the same with our classes in PHP.

Although the life cycle of the script is only one, but you can live it beautifully! This and try to do ...
Imagine that we have a social network (well, what about today without them? :)); There are users in this social network, and each user has a blog. And now we will try to display concisely and elegantly the spheres of action of each of the presented entities.
The user has a set of properties. Let it be: login, password and email. The user can perform some actions: login, logout, create a blog and write to it.
The blog, in turn, has properties: author, collection of topics and creation date. Blog can add a post.
We confine ourselves to this set of methods and properties of entities. How elegant is it to present a similar structure in code? I suggest the following option:

class Blog {
public $topics_list;
public $creation_date;
private $data; // ,

public function __construct($id) { //id
//- $this->data,
}

public function getAuthor() {
static $author; // , , , -

if (empty($author)) {
$author = new User($this->data[\'author_id\']);
}

return $author;
}

public function addTopic(Topic $topic) { ... } // .
}

class User { ... } // , ,


So - what have we achieved? Having created both classes in a similar way, as a result, we have clear areas of responsibility for each object; moreover, we will not wrap ourselves up with passing unnecessary parameters. For example, create a blog entry \ "in the old way \" and based on the described layouts.
In the old manner:

$user_id = $_SESSION[\'user_id\']; // id

$topic_message = \" \";
Blog::addTopic($user_id, $topic_message); //


Everything seems to be understandable and natural, except for one thing - when passing arguments to create a topic, the role of the user becomes not obvious. Let's see how the same code will look like with the new approach:

$user = new User($_SESSION[\'user_id\']);
$topic_message = \" \";

$user->getBlog()->addTopic($topic_message);


Here the relationship between the blog and the user is much more obvious ... And if you think that the topic is also an object and it has the property \ "message \", then we could get it like this:

$user = new User($_SESSION[\'user_id\']);
echo $user->getBlog()->getTopics()->topic[$topic_id]->message;


In such short examples, the benefits may not be very obvious, but when the code develops into a system of interaction of tens of hundreds, or even thousands of entities, the logic of each of them becomes more transparent and obvious, which affects the ease of support, extensibility and readability of the code. Not even for such a short life of the script ...

If after reading questions have appeared, I will be glad to answer them.

PS Tell me how to make out the code sections in the topics on Habré, but somehow it is not readable for me :(