Использование конструкторов для инициализации объектов. Внедрение зависимостей. Разница конструкторов сущностей и сервисов.
- 00:00:20 - Geometry
- 00:01:00 - Point
- 00:06:10 - Circle
- 00:10:34 - User
- 00:17:17 - Email
- 00:18:33 - Phone
- 00:21:00 - PHP
- 00:22:48 - Именованные конструкторы
- 00:26:30 - Сущности и сервисы
- 00:27:17 - PasswordHasher
- 00:28:52 - Handler
- 00:30:54 - ConfirmTokenSender
- 00:35:32 - Подведение итогов
Скрытый контент (код, слайды, ...) для подписчиков.
Открыть →Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Дмитрий, было бы не лишним для ваших слушателей, если бы вы рассказали о фундаментальных характеристиках программ. В частности, о таких понятиях как coupling и cohesion, на которых основываются все базовые принципы (например, SOLID) и шаблоны проектирования.
+
+
+
+
Моей ошибкой было начинать смотреть касты про аукцион, не ознакомившись с подходами, освещенными в серии "Взаимодействие объектов". Благодарю.
Кстати, будет здорово, если поделитесь мыслями о желательном порядке изучения Ваших материалов. А уже каждый подумает, какой у него уровень и с какого каста/курса начать.
Советую интенсив по ООП посмотреть - значительно поможет освоится.
А где этот интенсив?
На моём сайте https://elisdn.ru/products
Вопрос по разделению ответственности Сервисов
Есть сервис регистрации SignupService, который выполняет регистрацию пользователя.
В наш магазин мы добавляем возможность гостевого заказа, но чтобы сразу пользователя регистрировало на основе его данных. Получается такой метод:
Вопрос: Нам следует эту логику поместить в отдельный
SignupByOrderService
или можно оставить вSignupService
? Где та самая грань, когда надо создавать новый сервис?P.S. В данном случае оставил в SignupService.
Да, лучше сделать отдельный сервис, чтобы не смешивать разные способы регистрации в одном. В соседних скринкастах по аукциону мы всегда для каждой операции делаем отдельный класс-команду. Тогда вопросов с гранью не возникает.
Можно ли в сущности использовать сервисы?
В методе
signupByGuestOrder
с помощьюUsernameUniqueService
мы проверяем уникальность имени/генерируем уникальное:Но нам было бы удобнее генерировать
username
в именованном конструктореUser::requestSignupByOrder
, как мы это делаем с паролем:Можно ли в сущности использовать сервисы?
Можно, если сервис передавать в сам метод:
Об этом опубликовал статью о внедрении зависимостей в своём блоге.
Но понятнее будет вместо большого компонента
Security
передавать свой простой генератор, который внутри уже будет вызыватьgenerateRandomString
.Это будет удобно и в юнит-тестах, когда там будем делать стаб или мок для этого генератора.
Дмитрий, такой вопрос:
А разве такого вида не будет работать ? И делать уже внутри конструктора проверку на NULL
И чем плох такой метод?
Здесь отличие всего в двух параметрах, но их может быть больше. Например, для трёх способов регистрации пользователя может быть такой код:
Такой код плох неявностью. Непонятно, что и когда ему нужно передавать. Нужно будет отдельно прописывать к нему большую инструкцию.
Плох внутрренней запутанностью и сложностью. Внутри такого метода будет куча if-ов для проверки всех комбинаций.
Плох связанностью. Любое добавление или изменение параметров для изменения или добавления каждого способа сразу сломает кучу кода и тестов, которые дёргают этот метод.
А если у нас отдельные методы:
то всё понятно с первого взгляда, все методы без if-ов и изменение одного метеода никак не ломает другие методы и тесты.
В видео говорится что скрывать свойства объекта нужно для того чтобы какой-то другой разработчик их не мог "испортить". Это неверно, на самом деле сокрытие реализации нужно для того чтобы разработчики не писали код основываясь на деталях реализации объекта, так как код основанный на деталях реализации приводит к лишней связности (между объектами).
Не "неверно", а "не только". Защита от порчи и сокрытие деталей друг другу не противоречат, а дополняют.
Или войти через: