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

Корректное проектирование методов для описания поведения объекта. Инкапсуляция для контроля внутреннего состояния.

Скрытый контент
Комментарии (12)
Alex

Дмитрий, здравствуйте. Давно смотрю ваши скринкасты и проч. Сейчас оформил подписку чисто из благодарности.Хотя вижу, и здесь много полезного( как всегда). Если уместно сейчас выражать пожелания, - можно сделать урок о проектировании баз данных, хотя бы несложных. Я думаю это всем надо, а нормального материала,что бы быстро можно было усвоить, нет.

Ответить
Анатолий

Привет, подписку оформил, надеюсь будет мотивация продолжать свое дело. Хотелось бы записи о solid kiss dry

Ответить
Sergei

15:52 А разве не проще иметь предрасчитанную дату till_actual_date и сравнивать её? В плане быстродействия и дальнейших манипуляций.

Ответить
Дмитрий Елисеев

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

Ответить
Валентин

Дмитрий, возможно этот вопрос уже был, но что у вас за тема в phpstorm?

Ответить
Дмитрий Елисеев

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

Ответить
xfg

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

Ответить
Дмитрий Елисеев

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

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(), не ломая внешний код.

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

Ответить
xfg

Спасибо, теперь я понял вашу идею.

Ответить
Александр Панков

Здравствуйте, Дмитрий.

А подскажите пожалуйста почему на 21:26 в методе-запросе

$advert->getDate(){} : DateTimeImmutable

возвращается объект именно типа DateTimeImmutable, а не DateTime.

В чем преимущества и когда нужно возвращать иммутабельный объект, а когда нет, какие есть кейсы?

Я ни разу еще не видел ни в одной из библиотек такого подхода, везде DateTime выплевывают, иногда обернутую в Carbon.

Ответить
Дмитрий Елисеев

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

$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 делать иммутабельными одноразовыми. Вместо изменения внутреннего значения их просто целиком заменяют на новый объект.

Ответить
Александр Панков

Все понятно, спасибо!

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий