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

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

Скрытый контент
Комментарии (9)
Alex
2019-06-14 11:32

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

Ответить
Анатолий
2019-07-21 15:37

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

Ответить
Sergei
2019-12-07 00:05

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

Ответить
Дмитрий (Deworker Pro)
2019-12-07 08:57

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

Ответить
Валентин
2020-01-18 11:53

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

Ответить
Дмитрий Елисеев
2020-01-18 14:22

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

Ответить
xfg
2020-05-11 18:43

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

Ответить
Дмитрий (Deworker Pro)
2020-05-13 11:56

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

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
2020-05-15 19:27

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

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