Использование конструкторов для инициализации объектов. Внедрение зависимостей. Разница конструкторов сущностей и сервисов.
- 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
И чем плох такой метод?
В видео говорится что скрывать свойства объекта нужно для того чтобы какой-то другой разработчик их не мог "испортить". Это неверно, на самом деле сокрытие реализации нужно для того чтобы разработчики не писали код основываясь на деталях реализации объекта, так как код основанный на деталях реализации приводит к лишней связности (между объектами).
Или войти через: