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