Проектирование методов объектов

А, кстати, да )

+.

В "Интенсив по ООП" есть. Но соглашусь, что обновленный материал не помешает, т.к. интенсив в олд-скульном формате на 30 часов хронометража :)

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

Настраиваю сам.

Если программировать бизнес-логику проверки снаружи объекта:

if ($post->getStatus() === Status::PUBLISHED && $post->getPublishDate() >= $date) {
    throw new DomainException('Post is not published yet.');
}

то прямые геттеры get нужны. Состояние приходится доставать наружу. И любое изменение полей внутри объекта может привести к слому таких проверок.

Доступ к этим полям можно замаскировать в методы is, привязанные к этим полям:

if ($post->isStatusPublished() && $post->isPublishDateGreaterThan($date)) {
    throw new DomainException('Post is not published yet.');
}

Но от этого ситуация не очень меняется, так как мы всё равно продолжаем снаружи работать напрямую с полями status и publisDate по отдельности.

Но вместо этого можно инкапсулировать поведение и эту же бизнес-логику сокрыть внутрь именно "настоящего" метода:

if ($post->isPublishedForDate($date)) {
    throw new DomainException('Post is not published yet.');
}

Тогда прямые отдельные методы get и is для поштучного извлечения или оценки значений нам уже не пригодятся. И мы здесь можем как угодно изменять имена и типы полей и внутренности метода isPublishedToDate(), не ломая внешний код.

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

Если рассматривать мутабельные объекты-значения, то если кто-то напишет такой код:

$date = new DateTime();
$advert->setStart($date);

$date->modify('+1 hour');
$advert->setEnd($date);

то после сохранения обнаружит, что в start и end запишется одинаковая дата.

Это потому, что когда мы работаем с объектами:

$a = new A(12);

echo $a->value; // 12

в переменной находится указатель на объект. И при присваивании его в другие переменные:

$b = $a;
$c = $a;

echo $с->value; // 12

копируется не сам объект, а указатель на него. И во всех переменных будут указатели на один и тот же объект. В итоге если мы поменяем значение в c у нас поменяется значение и в a:

$c->value = 5;

echo $a->value; // 5

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

Так что если нам нужны две отдельные даты, то чтобы не было проблем нам нужно сначала склонировать первую дату и уже менять этот клон:

$start = new DateTime();
$advert->setStart($start);

$end = clone $start;

$end->modify('+1 hour');
$advert->setEnd($end);

Так и у нас вызов modify второй даты не изменит значение первой.

Аналогично у нас есть опасность, что кто-то напишет так:

$start = $advert->getDate()
$start->modify('+1 hour');

забыв склонировать оригинал. И этим он через геттер изменит нашу дату внутри advert.

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

$start = new DateTimeImmutable();
$advert->setStart($start);

$end = $start->modify('+1 hour'); // создаёт клон с другой датой
$advert->setEnd($end);

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

Поэтому популярна практика все объекты-значения вроде Id, Email, Phone делать иммутабельными одноразовыми. Вместо изменения внутреннего значения их просто целиком заменяют на новый объект.

Репозиторий нужен только для самого агрегата. Будет только AdvertRepository, который умеет сохранять Advert целиком с фотографиями. Фотографии здесь мы не используем самостоятельно отдельно от объявлений, поэтому отдельный репозиторий для фотографий нам здесь не нужен.

А в поле $photos будет простой массив или коллекция, создаваемая в конструкторе:

public function __construct(int $id, string $content) 
{        
    $this->id = $id;
    $this->content = $content;

    $this->photos = new ArrayCollection();
}

В случае Doctrine ORM это может быть её коллекция ArrayCollection для связей.

На счёт возврата null это часто зависит от языка программирования.

В PHP и Kotlin есть возможность через nullable-тип вроде ?User явно указать, что метод вернёт объект юзера или null:

class Repo
{
    public function a(): User
    public function b(): ?User
    public function c(): User
}

Поэтому можно спокойно возвращать null, и статические анализаторы и IDE подскажут, если мы забудем выше проверить на if (x === null). Там проблем с этим нет.

А в Java, наоборот, такой возможности нет:

class Repo
{
    public User a()
    public User b()
    public User c()
}

Там если указан тип User туда можно всё равно вернуть или присвоить null. И анализатор и компилятор это проследить не могут. В итоге если из метода с типом User вернуть null, то код выше свалится с NullPointerException.

Поэтому в Java есть общепринятая договорённость никогда не возвращать null. Вместо этого принято кидать исключения, возвращать объект Null Object или оборачивать необязательный результат в объект Optional:

class Repo
{
    public User a() throws NotFoundException
    public Optional<User> b()
    public User c() throws NotFoundException
}

А если брать функциональное программирование, то там активно используют монады вроде Either.

Да, как раз избавляет написания громоздких геттеров, которые делали для защиты полей от записи.

Также есть идея вынести Eloquent в инфраструктуру и написать свой mapper. Туда же вынести реализацию интерфейса репозитория(EloquentRepositrory). Что думаете насчет этого?

Закрыть атрибуты не очень получится. Там лучше программистам договориться не присваивать поля напрямую, а всегда вызывать бизнес-методы.

Если сильно заморачиваться, то в проектах на Yii я иногда делал бизнес-сущности из его ActiveRecord так. Может что-то подойдёт для Laravel.

Можно разбить на отдельные классы с общим id.

Например, сейчас можно основу оставить в Advert(id, author, category, tags), описание вместо вложенного объекта вынести в отдельнй объект Content(id, title, description, photos), состояние модерации в State(id, date, status, note) или даже в конечный автомат из группы классов-состояний вроде Draft, Moderation, Active, Rejected.