Что делать если зависимостей у класса становится очень много?

Question

[dmitriy]

Использую анемичную модель при разработки, соответственно активно используется Service, Repository и инфраструктурные зависимости Request, Configs, FormBuilders, Logger и тд в конструкторах.
Что делать если зависимостей идущих через конструктор становится очень много больше 5 и местами 10 ?

п.с Благо сборкой и инъекцией зависимостей занимается Autowaring DI, но все же.

Answer 1

[Mikhail Osher]

Шаблон фасад (англ. Facade) — структурный шаблон проектирования, позволяющий скрыть сложность системы путём сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы.

Comments

[dmitriy]

Вот по поводу него я и думал

[Mikhail Osher]

diamond, возможно, это не именно то, что Вам нужно, но, в целом, присмотритесь к структурным паттернам.

Answer 2

[bkosun]

А у вашего класса на самом деле есть жесткая зависимость? Если некоторые из зависимостей являются необязательными, возможно нужно подумать о том, чтобы удалить их из конструктора и использовать сеттеры?

Соблюдается ли принцип единой ответственности?
https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%B8%D...
https://en.wikipedia.org/wiki/Single_responsibilit...

Answer 3

[Антон Шаманов]

1. Задуматься почему так получилось и по возможности разграничить.
2. Не забывать что эстетика это конечно хорошо, но клиенту важнее производительность - отцы как бэ открытым текстом говорят - хочешь бложик, так не выеживайся - слепи по быстрому, а если что рефакторинг уже изобрели.

Comments

[Антон Тихомиров]

Рефакторинг на PHP? Круто! Это IDE должны уметь? И какие умеют если так? Вопрос без подвоха)

[Антон Шаманов]

Антон Тихомиров, а что собственно Вас удивляет в рефакторинге PHP кода? Базовые функции для рефакторинга (авто геттеры\сеттеры, дробление классов, ослабление связей) реализованы в крупных ide, (zend studio, phpstorm).

[Антон Тихомиров]

Собссно меня удивляет возможность рефакторинга в языках с динамической типизацией. Например, мне нужно переименовать метод myMethod () в классе MyClass. Я решил сделать это здесь:

function myFunct ($myClass) {
    return $myClass->myMethod ();
}

Дак вот как IDE поймет, что этот метод находится именно в классе MyClass, а не в каком-нибудь другом, который тоже имеет метод с похожим названием, но который я переименовывать не планирую? Если такое невозможно, то значит это уже не рефакторинг. Просто в той же Яве мы принудительно присваиваем переменной нужный тип данных, и компилятор понимает, что этой переменной присвоен экземпляр класса MyClass, например.

Я просто раньше тоже писал на PHP, сейчас на Яве, но планирую вернуться на него снова как закончу проект, вот и узнаю.

[Антон Шаманов]

Антон Тихомиров, в большинстве случаев ide либо парсят phpdoc метода либо отслеживают переменные в памяти. в 7ке появилась возможность задать более жесткую типизацию, в старых версиях это можно сделать хаком.

[Артур]

Антон Тихомиров, никто не мешает вам писать так:

function myFunct (MyClass $myClass) {
    return $myClass->myMethod ();
}

либо указать тип в phpdoc, IDE поймут и то и другое.

[Антон Тихомиров]

Антон Шаманов ооо, отслеживать переменные в памяти - отличная идея, потому-что phpdoc я не веду) Ясно, спасибо, буду знать.

[Антон Тихомиров]

Артур, ого! Это для семерки? И что, любую переменную можно так инициировать?

[Артур]

Антон Тихомиров, то что выше есть уже давно, точно не помню, но в пятой ветке вроде всегда было.
В 7-ом дополнительно появилась возможность указывать примитивные типы (int, bool и т.п.) для аргументов, а также задавать возвращаемый тип.

[Антон Шаманов]

Антон Тихомиров, с 5.2

[Антон Тихомиров]

Да ладно, даже 5 ветка поддерживает типизацию?! Она же появилась когда я еще в школе учился) Вот это да, надо бы проверить на досуге, до сих пор не верится. Просто ни разу ни в одном проекте не встречал.

Answer 4

[Дмитрий Афонченко]

Возможно глупый совет, но мне помогает обычно следующее.

Если у меня есть, к примеру Repository и Service и у меня ответ из репозитория обрабатывается методами сервиса, при этом сервис больше нигде не используется, то
1) Создаю новый интерфейс. Например FiltrationDataServiceInterface и передаю его в раздувшийся конструктор вместо этих двух классов.
2) В реализации интерфейса уже использую их для какого-то одного метода.
3) Этот метод использую в изначальном классе, зависимости, которого я хотел уменьшить.

Так можно объединять несколько сервисов в один и уменьшать количество зависимостей у раздувшегося класса.

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

Answer 5

[Vilintritenmert]

Впечетление что у класа за много ответственостей... нарушение Single Of Responsibility

Answer 6

[makeey]

Советую почитать книгу. А так же как уже было сказано почитать про SOLID. По поводу "эстетики" не согласен, потому как в дальнейшем будет сложна поддержка кода.

Comments

[Антон Тихомиров]

А можно поподробнее в плане эстетики? Вроде бы чем эстетичнее, тем легче поддерживать, ибо все функции выполняют то что нужно, все интерфейсы и методы на месте и называются так, как и должны, и т. д.