Как прекратить создавать объекты классов?

Question

[zvonok1337]

Здравствуйте, решил все-таки научиться хоть немного программировать по-взрослому, и вот.. имею проект в разработке, везде присутствует следующий код в классах. Мне не комфортно, что приходится создавать объект в __construct, чтобы пользоваться им в классе.

class TaskKey_Model
{
    private $database;
    private $user;
    private $task;

    public function __construct()
    {
        $this->database = new Database();
        $this->user = new User_Model();
        $this->task = new Task_Model();
        ..... и так далее
    }
}

Очевидно, что Database() можно вынести в отдельную модель, типа ActiveRecord, и просто наследовать её, а как тогда поступить с User_Model и прочим? Как не объявлять его постоянно? (перевести все в activerecord и вызывать статично, да?) а какие еще есть варианты

Answer 1

[Игорь Воротнёв]

Очевидно, что Database() можно вынести в отдельную модель, типа ActiveRecord,

Она у вас и так вынесена, в класс Database.

и просто наследовать её

А вот этого делать не стоит. От слова совсем.

Есть такая штука, Dependency Injection (DI). Почитайте. Возможно, не сразу вкурите. Но это необходимо понять и научиться с этим работать.

Должно быть как - у вас есть контейнер, который знает все ваши классы / сервисы (они регистрируются в него или с помощью Service Locator подтягиваются). Он же (контейнер) держит в себе инстансы этих классов - при первом вызове класса он инициализируется 1 раз и сохраняется в контейнере. При последующих обращениях контейнер возвращает уже существующий инстанс. Инициализацию сервисов в конструкторах делать не надо, это жестко связывает ваш код и ведет в никуда. Зависимости надо подкидывать через конструктор, параметрами.

Comments

[Stalker_RED]

Правда Service Locator практически на каждом углу называют анти-паттерном, но это мелочи, правда?

[Игорь Воротнёв]

Stalker_RED, я дал на выбор Dependency Injection и Service Locator. Паттерн или антипаттерн - это топикстартеру выяснять надо будет сильно позже. На данном этапе для него это дополнительная почва для размышлений, которая приведет к чтению нужных материалов и поможет сложить в голове общую картинку.

Answer 2

[Vasiliy_M]

Очевидно, что Database() можно вынести в отдельную модель, типа ActiveRecord

объект для работы с СУБД никоим образом не относится к паттерну AR. AR не должна наследоваться от объекта СУБД.

и просто наследовать её

https://refactoring.guru/ru/replace-inheritance-wi...

Мне не комфортно, что приходится создавать объект в __construct, чтобы пользоваться им в классе.

это ваши проблемы. точнее это вообще не проблема, что в конструкторе создаются объекты.
учитесь мыслить независимыми объектами. учитесь складывать из кирпичиков механизм, в котором нет жёсткой связанности. приведенный код как раз это и обеспечивает.

Здравствуйте, решил все-таки научиться хоть немного программировать по-взрослому

прочти хотя бы 1/3 этой книги

Answer 3

[Максим Федоров]

Проблема Вашего кода это сильная связанность со всеми вытекающими. В такой ситуации как минимум стоит применить SOLID-принципы, как максимум - переработать архитектуру приложения (но тут конечно все зависит от масштаба проекта).

Рекомендую почитать:
Robert Martin - Agile Software Development, Principles, Patterns and Practices
Martin Fowler - Patterns of Enterprise Application Architecture

Comments

[Vasiliy_M]

в его коде как раз нет никакой связанности

[Максим Федоров]

Vasiliy_M, то что в объекте есть агрегация еще не говорит о том что код не связан. Этот код ЗАВЯЗАН на конкретную реализацию объектов - а значит и связанность их высока.

[Vasiliy_M]

Максим Федоров, 90% классов завязаны на реализацию агрегируемых объектов и что с того?

[Максим Федоров]

Vasiliy_M, 90% на каких-нибудь pet-проектах которые живут себе мирно на протяжении многих лет и которые никто не трогает - возможно. На серьезных проектах - нужно использовать абстракции, иначе проект может и не пережить следующие изменения, точнее понимать где использовать абстракции, а где можно и без них обойтись.

[Оптимус Пьян]

Максим Федоров и Vasiliy_M Объясните мне плиз для тупых простыми словами )) Было (сейчас):

public function __construct()
    {
        $this->database = new Database();
    }

Стало (сделает DI):

public function __construct(Object $db)
    {
        $this->database = $db;
    }

Понятно что объект пришёл снаружи уже готовый, но что изменилось по существу и на что это влияет?

[Максим Федоров]

Оптимус Пьян,
во втором случае если вы не укажите при создании объекта, то будет ошибка (это хорошу к слову)
также вы можете потом заменить на интерфейс, ну например так DBInerface $db

[Оптимус Пьян]

Максим Федоров, но в первом случае я могу свободно делать объекты где мне надо:

$obj = new MyClass();
$obj = new MyClass();

А во втором мне надо пихать везде БД каждый раз при создании

$obj = new MyClass($db);
$obj = new MyClass($db);

А откуда мне взять здесь $db? Она должна быть в глобалке? Или в свою очередь мне теперь уже здесь в конструкторе надо $db откуда-то подтянуть что бы потом передать?

[Максим Федоров]

Оптимус Пьян, нет, не нужно в глобалке... вообще работа с БД по-другому нужно реализовать
Где правильно подключать БД в MVC в PHP? смотрите ответ от OnYourLips

[Vasiliy_M]

Оптимус Пьян,

Понятно что объект пришёл снаружи уже готовый, но что изменилось по существу и на что это влияет?

в данном (не совсем удачном примере, т.к. менять объект для подключения БД - редкость) мы можем заменить объект БД другим объектом БД, который подключен к другому серверу.

public function __construct()
    {
        $this->database = new Database();
    }

- это плохой код, я соглашусь с Максим Федоров, я не совсем был прав - лучше объекты передавать в класс через set-методы, это будет меньшая связанность.

[Vasiliy_M]

Оптимус Пьян,

А откуда мне взять здесь $db? Она должна быть в глобалке?

это вопрос архитектуры конкретной, не имеющий отношения конкретно к твоему глобально-теоретическому вопросу о связанности объектов.

[Оптимус Пьян]

Vasiliy_M, я о том, что развязал в одном месте - связал в другом, просто переместили это действие из одного конструктора в другой, скорее всего в конструктор контроллера

[Евгений Педя]

Во втором случае можно класс Database менять на что угодно, но согласно интерфейса.
За счёт DI объект будет создан сам. Но можно передать нечто ручками. По этому можем тестировать имитируя Database. (Для фриланса и плюшевых проектов TDD в игноре, но всё же актуален.)

Даже для плюшевых проектов порой смена Database нужна. Впрочем у меня был доступ не к БД, а к сайту через запрос xml файла с парсингом айтемов. Сделал в виде репозитория. Далее через пару месяцев сервис отдававший (кривой xml) создал API. Правка репозитория оказалась быстрой.

А ещё через неделю потребовалось для других URL другой сервис, но в те же айтемы. Другой репозиторий. Получаем его через фабрику, которая отдаёт и первый, но зависимо от URL ресурса. Часть которая работала с самими айтемами не изменилась нисколько.

Answer 4

[artem78]

Можно использовать шаблон Registry.