Ждем продолжения! В видео вы упомянули про мониторринг обращений к функции - через что это лучше делать? Хотелось бы еще несколько примеров с расширением, модификацией интерфесов.
Способов мониторинга много - от банального логгирования до использования инструментов мониторинга и трассировки вроде Sentry, Zipkin или Jaeger. В качестве примеров модификации и расширения интерфейсов я хотел привести в качестве примера структуру интерфейсов репозиториев из Spring Data, но в процессе работы над материалом идея вылетела из головы.
@@shurik_codes есть какой то аллертинг, от обратного!? Те прошло хх дней и метод У/ деприкейтед не использовался, можно удалять?! Пс за ролики спасибо 😊
Спасибо за видео. Вопрос: а если мне нужно добавить через некоторое время метод findByEmail, интерфейс я менять не могу. Новый заводить? а если заведу новый, нужно ли старый туда тож имплементить (в реализацию имею ввиду)? и как потом пользоваться? Вот я создал сервис, там могу искать по имейлу или по айди, придется 2 класса инжектить? можно ли как то все же обойтись одним? те хочу в сервис инжектить только personalRepository но при этом чтобы там появлялся новый функционал. И как быть с сервисами?) вот у меня в сервисе был метод только поиска по айди а теперь как и в репозитории тож появился метод на поиск по имейлу, но сервис я изменить же тоже не могу получается? и что тогда делать? создавать новый сервис?)
Оптимально - заводить новый интерфейс, его можно реализовывать в существующем классе, а можно в отдельном. Но в любом случае внедрять зависимости нужно будет по интерфейсам. Хотя стоит отметить, что этот принцип больше связан с публичными API, предоставляемыми другим библиотекам и приложениям, если тот же репозиторий реализуется для самого себя, то можно вносить изменения и в интерфейс. А вот вносить изменения в существующие публичные REST API не стоит
Привет Слушай, а вот полиморфизмом что считается и не считается? 1. Мы можем создать интерфейс, который будут реализовывать разные два класса по-разному, и это полиморфизм для методов исходя из интерфейса 2. Мы можем сделать класс, у которого будут перегружены два метода, но имена методов одинаковые, сигнатуры разные, и это полиморфизм для методов исходя из одного класса Верно?
Если честно Мартин походу что то курил когда писал про этот принцип. Каждые 10 лет он звучит по другому. В 22 году в твиттере он опять написал что значит этот принцип, и он очень отличается от того что он писал изначально.
Спасибо!
Очень приятный голос и понятное объяснение, мне нравится. Классный канал!
Ждем продолжения! В видео вы упомянули про мониторринг обращений к функции - через что это лучше делать? Хотелось бы еще несколько примеров с расширением, модификацией интерфесов.
Способов мониторинга много - от банального логгирования до использования инструментов мониторинга и трассировки вроде Sentry, Zipkin или Jaeger. В качестве примеров модификации и расширения интерфейсов я хотел привести в качестве примера структуру интерфейсов репозиториев из Spring Data, но в процессе работы над материалом идея вылетела из головы.
@@shurik_codes есть какой то аллертинг, от обратного!? Те прошло хх дней и метод У/ деприкейтед не использовался, можно удалять?!
Пс за ролики спасибо 😊
Я такого не встречал, впрочем, и не скажу, что искал)
Лайк, коммент, пошел смотреть следующий ролик.
Очень круто!
круто, полезно, спасибо!
Отлично!
Очень хотелось бы увидеть ролик про кэширование.
Good job!
Спасибо за видео. Вопрос: а если мне нужно добавить через некоторое время метод findByEmail, интерфейс я менять не могу. Новый заводить? а если заведу новый, нужно ли старый туда тож имплементить (в реализацию имею ввиду)? и как потом пользоваться? Вот я создал сервис, там могу искать по имейлу или по айди, придется 2 класса инжектить? можно ли как то все же обойтись одним? те хочу в сервис инжектить только personalRepository но при этом чтобы там появлялся новый функционал. И как быть с сервисами?) вот у меня в сервисе был метод только поиска по айди а теперь как и в репозитории тож появился метод на поиск по имейлу, но сервис я изменить же тоже не могу получается? и что тогда делать? создавать новый сервис?)
Оптимально - заводить новый интерфейс, его можно реализовывать в существующем классе, а можно в отдельном. Но в любом случае внедрять зависимости нужно будет по интерфейсам.
Хотя стоит отметить, что этот принцип больше связан с публичными API, предоставляемыми другим библиотекам и приложениям, если тот же репозиторий реализуется для самого себя, то можно вносить изменения и в интерфейс. А вот вносить изменения в существующие публичные REST API не стоит
@@shurik_codes спасибо
Может лучше делать примеры на Kotlin ?
Чем лучше?)
Привет
Слушай, а вот полиморфизмом что считается и не считается?
1. Мы можем создать интерфейс, который будут реализовывать разные два класса по-разному, и это полиморфизм для методов исходя из интерфейса
2. Мы можем сделать класс, у которого будут перегружены два метода, но имена методов одинаковые, сигнатуры разные, и это полиморфизм для методов исходя из одного класса
Верно?
Первое - это наследование, а вот второе - это полиморфизм
Если честно Мартин походу что то курил когда писал про этот принцип. Каждые 10 лет он звучит по другому. В 22 году в твиттере он опять написал что значит этот принцип, и он очень отличается от того что он писал изначально.