When I worked on another project, I met an interesting opinion. They say, all the code in the project should be as open as possible by default. I.e. we should make all new methods and fields public, and we should not put final anywhere, except some special cases when it's really necessary. It was motivated with the difficulties of further codebase support:

If I want to inherit the class, and there is a private method, I have to study the code to understand why it was made private and whether I can make it public.

This opinion was very unusual for me, and I decided to figure it out if there is really more problems when fields and methods are private by default.
Let's write an extra public method and see how easy is it to support it.

interface FooInterface {
  public function foo();
}

class Foo implements FooInterface {
  public function foo() {
    // do stuff
    $this->bar();
    // do stuff
  }

  public function bar() {
    // do stuff
  }
}

With this article, I open a rubric "Don't do this." It will contain code from real projects, from which I will remove all references to the projects themselves. And, of course, my explanations of why shouldn't you do this, and the way it should be done.

So, the first patient. Inside the trait, the fields of its descendants are used. I mean something like this:

trait Foo
{
    public function bar(): string
    {
        return $this->field . static::CONSTANT . $this->method();
    }
}

When an IT product evolves, there always comes a time when it becomes necessary to bring some new tool into it or replace the old one with something more suitable. While it seems that a lot of articles have been written on the topic of choosing tools, and there is nothing new to say, the question still remains relevant, in some places even sharp.

Here are the most popular approaches:

• Find something hype on the left road
• Take something proven and reliable on the right road
• Go straight ahead and use your favorite tool

They are good because you don't have to think when using them. You just take what you want - and that's it 😃 Well, if there is a need or a desire to approach the issue more seriously - welcome under the cut, we'll figure it out.

There are many architectural patterns in the development world. Some of them we use every day, some - less often. Surely each of you has seen the Singleton and the Factory many times. Many of you have written them on your own. But when I first read about the Builder pattern, at first I did not understand in what situation it can be applied. What is completely ridiculous: I regularly used its implementation (QueryBuilder from the Yii framework), but my eye was so blurry that I could not match the name and functionality of this class and the corresponding design pattern 😂 Of course, after a while it dawned on me. And over more time, a situation was found in which the Builder pattern fit perfectly.

The question of the area of responsibility of a particular class in a program architecture is no less important than architecture strategic planning. Today I will tell you how to make this job easier for yourself. We will solve a fairly large number of issues, leaving only two types of classes out of an infinite variety: DTO and Service. These types cover 90-99% of everything needed in any project. So, let's look at what they are, and why it's so good to leave only them.