Почему целесообразнее не использовать new для работы с классами, а предпочесть DI?

Question

[Слава]

на проекте, куда попал, принято каждый сервис вызывать внутри функций других классов в виде
(new MyService())->getData() - к примеру.

Но у меня было убеждение, что тогда уж лучше в конструктор класса прокинуть его:
private readonly MyService $service;

или прям в метде контроллера:

public function store(Request $request,  Myservice $service)
{
   $newData = $service->getData($request->all());
}

в общем можете мне с точки зрения целесообразности объяснить как правильнее?

Comments

[JhaoDa]

Шли годы разработки на ларавел и вдруг Слава открыл для себя DI...

[Слава]

JhaoDa, ты хотя бы читаешь содержание поста прежде, чем написать комментарий? там написано, что пришел на проект и везде используют new в этом проекте. а я привык использвоать di. и попросил пояснить за неправильность подхода с использованием new/

[JhaoDa]

Слава, у человека, который знает и понимает DI, такого вопроса бы не возникло.

Answer 1

[Алексей Уколов]

Вот почему: PHPunit замокать класс внутри тестируемого класса?
Бонус-раунд: DI упрощает работу с зависимостями зависимостей. Если ваш MyService принимает какой-нибудь логер в зависимостях, который в свою очередь ожидает какой-нибудь драйвер файловой системы, вы задолбаетесь собирать их через new.

Answer 2

[Дмитрий Энтелис]

Главные аргументы против new.
1. Невозможно написать unit-тест на класс
2. Нельзя сделать то что написал devian3000 в своем примере
3. По коду непонятно от чего зависит класс.
4. Хорошие контейнеры обеспечивают переиспользование уже созданных классов, что может давать выигрыш в скорости

Answer 3

[devian3000]

Правильнее через внедрение зависимости (в частности DI).
В конструктор нужно передавать интерфейс.
Простой пример, в зависимости от настроек нам нужно отправить сообщение или через email или просто записать в файл для отладки, тогда

interface MessageProviderInterface {
    public function sendMessage($from, $to, $text);
}

class Email implements MessageProviderInterface{}
class File implements MessageProviderInterface{}

class NewService {
   private MessageProviderInterface $provider;
   public function __construct(MessageProviderInterface $provider) {
      $this->provider = $provider;
  }
}

$provider = getenv('ENV') === 'DEBUG' ? new FileProvider() : new EmailProvider();
$service = new NewService($provider);

Это буквы I и D в принципе SOLID.
DI контейнер просто позволяет проще регистрировать эти зависимости (не только но в основном)

Comments

[Слава]

а вы могли бы сказать доводы именно против использования new ?

[devian3000]

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

если каждый раз вызывать new то это и по perfomance такое себе, выделение памяти, процесорное время, если это делать часто то есть определенный оверхед (тут конечно надо смотреть на ситуацию, DTO предположим вполне себе нужно создавать каждый раз на разные данные)

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