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

Question

[topuserman]

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

Какие есть варианты упрощения ? чтобы при создании объекта не передавать кучу параметров в конструкторе.

И также сразу второй вопрос: можно ли в классе-сущности создать метод, который будет создать свой объект:

например так (чтобы каждый раз не писать код создания объекта):

public static function create(int $id): self {
     $order = App\Data\Order::getById($id);
     $user = App\Data\User::getById($order->getUserId());
     return new self($order->getId(), ... $user->getOtherData(), ..);
}

Comments

[Антон Р.]

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

- А можно пример такой сущности? Просто интересно как это может не получаться.

[topuserman]

Антон Р., а что тут удивительного ?
например сущность пользователь:
ид,
имя,
фамилия,
отчество,
фото,
тип,
права,
логин,
емейл,
телефон,
адрес,
менеджер,
комментарий менеджера,
дата регистрации,
дата последней авторизации,
в сети или нет,
компания,
и т.д.)

[topuserman]

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

[Антон Р.]

topuserman,

имя,
фамилия,
отчество,
фото.

-----

тип,
права,
логин,
дата регистрации,
дата последней авторизации,
в сети или нет,

----

емейл,
телефон,
адрес,

Вот примерно раскидал, как эти сущности назвать уже твоя задача.

[Дмитрий]

Добрый день.
Вам тут уже посоветовали обратить свой взор на статьи от Дмитрия Елисеева.
Дополню конкретной ссылкой.

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

Ну как-то так

class Member
{
    public function __construct(Id $id, Group $group, Name $name, Email $email, Address $address)
    {
        $this->id = $id;
        $this->group = $group;
        $this->name = $name;
        $this->email = $email;
       $this->address = $address;
        $this->status = Status::active();
    }
}

        $member = new Member(
            $id,
            $group,
            new Name(
                $firstName,
                $lastName
            ),
            new Email($email),
            new Address(
                $country,
                $city,
                $street
            )
        );

Answer 1

[FanatPHP]

Разделить сущность на несколько мелких сущностей не получится.

Это тебе только так кажется.

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

Вот очень хороший доклад от Дмитрия Елисеева (который, на мой взгляд, является на данный момент лучшим в России популяризатором ООП в РНР). Видео стоит посмотреть целиком, но конкретный ответ на твой вопрос начинается на 27 минуте: https://youtu.be/6tL1XOywgUc?t=1653

Answer 2

[Евгений Вольф]

Какие есть варианты упрощения ? чтобы при создании объекта не передавать кучу параметров в конструкторе.

На вскидку, вариантов несколько:
1. Передавать не 20 десятков свойств, а именованный массив, например так:

__construct($array) { ... }

new MyClass([
    'property1' => 'value1',
    'property2' => 'value2',
    'property2' => 'value3',
]);

А в самом классе соотв. заполнять те поля которые не переданы - значениями по умолчанию (если это допустимо), так будет несколько более читабельно.

2. Либо же, если проблема конкретно в конструкторе - можно передавать эти значения через другой метод, не конструктор.

3. Или, можно где-то сохранять эти значения (в конфиге, в БД, в сессии, где-то-ещё) и при создании экземпляра нужного класса - доставать их оттуда (такая практика встречается довольно часто).

Comments

[necrodeflorator]

Позвольте встрять :)
На самом деле 3 вариант - очень фиговое решение с точки зрения автотестов, придется готовить окружение для теста. Гораздо проще передать моки в контруктор

[FanatPHP]

necrodeflorator, ты ему льстишь. тут все пункты - ад.
типичное решение проблемы на уровне джуниора: "вижу проблему, ищу доступное своему кругозору прямолинейное решение".
И разумеется, предложенные варианты не имеют ничего общего с ООП, а показывают скромный, и по большей части воображаемый опыт автора ответа в написании пары функций на РНР

[Евгений Вольф]

necrodeflorator, в ряде случаев - окружение для теста может быть уже готово, такое тоже встречается не редко. Например, в тестах среди прочего не редко нужно тестировать и различные варианты работы с БД (т.е подключиться к БД и произвести какие-то операции). Откуда при этом возьмутся учётные данные для подключения к БД? Как вполне реальный вариант - они могут взяться из окружения.

К тому же, при текущей популярности Docker'а и построенных на нём систем автоматического тестирования (в принципе и не только на нём...) - настройка окружения - может быть в т.ч. и неотъемлемой частью такой системы.

P.S. Не обращай внимания на г-на FanatPHP, он уже давно обитает в своём скромном и по большей части воображаемом мирке и будучи ни на что более полезное не способным [например давать свои собственные ответы, а не только критиковать чужие], кроме как гадить в комментариях преимущественно занимается именно этим.

[necrodeflorator]

Евгений Вольф, ох)
По ПХП я не буду вступать в полемику.

А вот Фанат был модератором сообщества пхп в жиже еще когда я только начинал свою карьеру. Я боюсь вы в разных весовых категориях, чтобы с ним бодаться)

[FanatPHP]

necrodeflorator, чтобы не быть голословным - п.1 мало того что не решает проблему, а скорее её усугубляет (количество параметров не уменьшается, а наоборот добавляется писанины), но главное - это убивает одно из важнейших достижений РНР последних лет - строгую типизацию. Поскольку в параметрах мы можем использовать типизацию, а в массивах - нет.
п.2 тоже не решает проблему, а только её делегирует в другой метод.

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

[Евгений Вольф]

necrodeflorator, тут ключевое слово "был". Судя по уровню интеллекта, когда я начинал свою карьеру - он ещё в планах только "был" (а может и не был, иногда такое тоже случается). Но, не зависимо от того, кто кем когда-то был - это не даёт кому-либо права на прямые оскорбления основанные лишь на собственном скудоумии и доводах. ВАЗ-2106 тоже когда-то был новой моделью и желанным для многих автомобилем... И FreeBSD тоже когда-то был мейнстрим серверной ОС, и перфокарты тоже когда-то были пиком компьютерных технологий... У нас же тут не клуб ветеранов, что бы обсуждать кто когда-то кем-то был и бряцать "медалями".

[Евгений Вольф]

necrodeflorator, что бы не быть голословным, пунктов там 3, а не 2 (описанных выше). "Важнейшее достижение PHP" в виде частичной типизации - на данный момент важнейшим является лишь для определённого круга лиц и задач, так как каких-то глобальных профитов оно в себе не несёт, кроме как сокращение потенциального кол-ва возможных ошибок, в т.ч. об этом говорили сами разработчики ПХП когда ввели это "важнейшее достижение". К тому же, автор вопроса ничего не говорил о том, что у него активно используется типизация, о том, что она ему нужна в обязательном порядке или чего-то подобного. Так же как и он не говорил о том, что она в принципе допустима. Да, бывают такие случаи, когда переменная может иметь разные типы в зависимости от ситуации и это может быть вполне нормальным для конкретной программы на PHP. А UnionTypes, как "важнейшее достижение последних лет" - в релиз ещё не вышли (я имею в виду в релиз в этом мире, в реальном, в воображаемых мирах возможно всё), так как появились в PHP v8. Тут как раз и проявляется разница между чьим-то воображением и реальной ситуацией. Я не додумываю за автора вопроса, я основываюсь на том, что есть по факту, на том, что озвучил автор, а не на "идеальной модели мироздания" или воображении.

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

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

[necrodeflorator]

Евгений Вольф, FanatPHP
Вы мой ник тегаете, чтобы друг с другом спорить? :) Коллеги, давайте конструктивней)
Автор спросил, все дали ответ и комментарии. Давайте не будем плодить токсичность, пожалуйста

[Евгений Вольф]

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

[FanatPHP]

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

[Евгений Вольф]

FanatPHP, знатные приходы, отсыпь!

Answer 3

[Кирилл Горелов]

https://refactoring.guru/ru/design-patterns/builder - как одно из решений

Answer 4

[necrodeflorator]

тот метод, что вы написали(create) - называется фабричный метод, ЕМНИП. Вполне рабочее решение, для скрипта "на коленке".

Можно так же почитать про другие порождающие паттерны проектирования, возможно поможет понять суть