Создание сущности или в каких случаях оправданы сеттеры?

Question

[nepster-web]

Как правило при работе с сущностями есть 2 подхода.
- вносить данные через конструктор
- вносить данные через сеттеры

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

Пример сущности:

<?php

class System
{
    private $id;
    private $alias;
    private $status;
    private $date;

    public function __construct
    (
        int $id,
        string $alias,
        Currencies $supportedCurrencies,
        SystemStatus $status,
        SystemServiceInfo $serviceInfo,
        Date $date
    )
    {
        $this->id = $id;
        $this->alias = $alias;
        $this->supportedCurrencies = $supportedCurrencies;
        $this->status = $status;
        $this->serviceInfo = $serviceInfo;
        $this->date = $date;
    }

    public function getId(): int
    {
        return $this->id;
    }

    public function getAlias(): string
    {
        return $this->alias;
    }

    public function getStatus(): SystemStatus
    {
        return $this->status;
    }

    public function getDate(): Date
    {
        return $this->date;
    }
}

в ходе этого я с толкнулся с такой проблемой, что когда нужно обновить 1 поле, нужно пересобрать сущность (да, тут конечно сеттер был бы к стати). На ум приходит только одно фабрика + полное создание новой сущности.

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

Как в таких случаях (собирать сущность) лучше всего поступать ?

Answer 1

[Fortop]

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

Если вы все таки желаете работать с иммутабельной сущностью, то нужно смириться с гидрацией её в массив и обратно.

Comments

[nepster-web]

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

[Fortop]

nepster-web:
За форматы данных отвечают мапперы, которые и выполняют гидрацию данных из массива в объект.

В простейшем случае можете посмотреть в сторону Zend\Hydrator

Answer 2

[novrm]

Смотри на контроллер и понимай, что если внедрений нужно сделать тысяча - контроллер раздуешь до беспредела.
Сеттеры - лучшее решение.
Кроме того сеттеры и геттеры можно легко засунуть в трейт - кода станет меньше.
А внедрение сделать не через фабрику - а через общий делегатор с общим ServiceManager.

Comments

[Fortop]

Кроме того сеттеры и геттеры можно легко засунуть в трейт - кода станет меньше.

Не самая лучшая идея, но иногда можно

[novrm]

Fortop: Объясните. В чем проблематичность?

[Fortop]

novrm:
трейты это горизонтальное наследование. Т.е. условно говоря общая часть между несвязанными классами.
Вы не можете зафиксировать их контракт. Никак. Вообще.

Поэтому вся проблема контроля лежит исключительно на программисте.

[novrm]

Fortop: Извините за дотошность.
Не совсем понял суть вашего ответа?
Можно пример? И где именно там контракт?

В трейте спокойно фиксируете проверку типов.
Например:

namespace Blog\Service\Traits;

use Blog\Service;

/**
 * PostServiceAwareTrait trait.
 *
 * @package Blog\Service\Traits
 */
trait PostServiceAwareTrait
{

    /**
     * $postService instance.
     *
     * @var Service\PostService
     */
    protected $postService = null;

    /**
     * Set $postService.
     *
     * @param  Service\PostService $postService
     * @return self
     */
    public function setPostService(Service\PostService $postService)
    {
        $this->postService = $postService;

        return $this;
    }

    /**
     * Retrieve $postService.
     *
     * @return Service\PostService $postService
     * @throws \InvalidArgumentException
     */
    public function getPostService()
    {                           /** Retrieve variable. */
        $postService = $this->postService;
                                /** Has been set instance from setter? */
        if ($postService instanceof Service\PostService) {
            return $postService;
        };                      /** Set instance from ServiceManager. */
        if (method_exists($this, 'getServiceManager')) {
            $postService = $this->getServiceManager()->get(Service\PostService::class);
            $this->setPostService($postService);

            return $this->postService;
        };                      /** Else return exception. */
        throw new \InvalidArgumentException(sprintf('"%s" expects object of "%s" class.', __METHOD__, Service\PostService::class));
    }

}

[Fortop]

novrm:

Смотрите.

Любой класс мы можем зафиксировать контрактом интерфейса.

class MyLiebeClass implements SomeInterface {}

С трейтом данная операция невозможна

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

func(SomeInterface $var) {}

Трейт так контроллировать нельзя.
Соответственно как только у вас возникает желание переиспользовать мало-мальски объемный кусок логики путем трейтов - вы плодите себе будущие проблемы.

[novrm]

Fortop: Я вас понимаю.
Речь идет о гетерах и сетерах. Зачем тут наследовать интерфейс?

[Fortop]

novrm:

Вот ровно до тех пор пока они только предоставляют доступ к полям и можно.

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

Answer 3

[dmitriy]

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

$system 
   = (new System(1))
        ->setStatus(5)
        ->setAlias(1)
        ->setServiceInfo($serviceInfo)
;