АОП. Аспектно-ориентированное программирование
Всем привет! С вами снова Андрей, java-разработчик. Мы продолжим говорить об экосистеме java и смежных вещах. Сегодня затронем АОП. Тема очень обширная, поэтому в этой мини-статье заденем минимальные основы.
В рамках Spring-фреймворка АОП является некой сквозной логикой, которую мы можем использовать в любом месте приложения, всего навсего повесив аннотацию (или с помощью xml-разметки). Также этот механизм используется почти во всех модулях фреймворка Spring, являясь фундаментом для построения более сложных механизмов.
Пару недель назад мы уже краем касались этой темы, когда рассматривали self-inject’ы и Transactional-аннотацию. Под этой аннотацией, как и под многими другими, как раз таки и скрывается механизм аспектно-ориентированного программирования.
Зачем нам нужно АОП? Данный функционал хорошо себя показывает в задачах, связанных с логированием или предоставлением доступов к каким-либо ресурсам. Чтобы не дублировать код наших логов по всему проекту, мы можем вынести это в одно место и вызывать (с помощью аспектов) перед выполнением метода или после. В случае предоставления доступов бывают ситуации, когда нам нужно проверить доступ к ресурсам исходя не только из токена (или любого другого ключа) пользователя, а из данных, которые находятся, например, в базе данных. Есть ли у пользователя X доступ к скачиванию этой фотографии или архива с документами?
Давайте попробуем разобраться на простом примере (примеры будут сразу в следующих постах). Для начала, в pom.xml, вы должны иметь следующие зависимости: spring-boot-starter-web, spring-boot-starter-aop. Это минимальный набор, чтобы начать изучать spring aop. Рассмотрим самописные аспекты по логированию какой-то информации сигнатуре метода и по доступу к файлу.
#rdclr_backend #java
Всем привет! С вами снова Андрей, java-разработчик. Мы продолжим говорить об экосистеме java и смежных вещах. Сегодня затронем АОП. Тема очень обширная, поэтому в этой мини-статье заденем минимальные основы.
В рамках Spring-фреймворка АОП является некой сквозной логикой, которую мы можем использовать в любом месте приложения, всего навсего повесив аннотацию (или с помощью xml-разметки). Также этот механизм используется почти во всех модулях фреймворка Spring, являясь фундаментом для построения более сложных механизмов.
Пару недель назад мы уже краем касались этой темы, когда рассматривали self-inject’ы и Transactional-аннотацию. Под этой аннотацией, как и под многими другими, как раз таки и скрывается механизм аспектно-ориентированного программирования.
Зачем нам нужно АОП? Данный функционал хорошо себя показывает в задачах, связанных с логированием или предоставлением доступов к каким-либо ресурсам. Чтобы не дублировать код наших логов по всему проекту, мы можем вынести это в одно место и вызывать (с помощью аспектов) перед выполнением метода или после. В случае предоставления доступов бывают ситуации, когда нам нужно проверить доступ к ресурсам исходя не только из токена (или любого другого ключа) пользователя, а из данных, которые находятся, например, в базе данных. Есть ли у пользователя X доступ к скачиванию этой фотографии или архива с документами?
Давайте попробуем разобраться на простом примере (примеры будут сразу в следующих постах). Для начала, в pom.xml, вы должны иметь следующие зависимости: spring-boot-starter-web, spring-boot-starter-aop. Это минимальный набор, чтобы начать изучать spring aop. Рассмотрим самописные аспекты по логированию какой-то информации сигнатуре метода и по доступу к файлу.
#rdclr_backend #java
Telegram
RDCLR.DEV
Ловушка @Transactional или использование Self-inject’ов
В бине имеется 2 метода: a() и b(), помеченных аннотацией @Transactional. Если мы из метода а() вызовем метод b() — как поведет себя транзакция метода b()?
Правильный ответ — транзакция метода b() не…
В бине имеется 2 метода: a() и b(), помеченных аннотацией @Transactional. Если мы из метода а() вызовем метод b() — как поведет себя транзакция метода b()?
Правильный ответ — транзакция метода b() не…
Аспект для логирования сигнатуры метода. Связан через аннотацию LogSomething (написана вручную, в ней нет ничего особенного)
#rdclr_backend #java
#rdclr_backend #java
Аспект для логирования сигнатуры метода. Связан через аннотацию CheckFileAccess (написана вручную, в ней тоже нет ничего особенного)
#rdclr_backend #java
#rdclr_backend #java
Сервис, где методы будут помечены созданными аннотациями LogSomething и CheckFileAccess
#rdclr_backend #java
#rdclr_backend #java
Spring framework: под капотом
До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.
Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.
У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.
Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU
#rdclr_backend #java #read
До этого мы с вами разбирали основные инструменты фреймворка Spring, которые помогают сделать нашу разработку проще.
Настало время разобраться, как же работает та самая «магия» Спринга под капотом. С помощью каких инструментов создаются бины, инжект бинов, что такое в принципе понятие Бин. Весь процесс от запуска приложения, до его окончательного рабочего состояния. И в этом нам поможет довольно известный разработчик Евгений Борисов, который в своих лекциях посвящает нас в работу движка фреймворка на самом низком уровне. Для качественной разработки эти знания просто необходимы, поэтому на собеседованиях java-разработчиков довольно часто попадаются вопросы этой тематики.
У Евгения на ютубе имеется целый цикл лекций по Спрингу на самые разные темы. Предлагаю вам начать изучение с одной из самых популярных из его лекций — Spring-потрошитель. Не пугайтесь, что видео 2014 года: оно актуально и по сей день, ибо под капотом фреймворк почти не изменился.
Часть 1 https://youtu.be/BmBr5diz8WA
Часть 2 https://youtu.be/cou_qomYLNU
#rdclr_backend #java #read
Java. Какую версию выбрать?
Начиная с 2017 года релизная политика версий java в корне поменялась. Вместо продолжительных застоев в несколько лет с накоплением большого количества фич, было принято решение перейти на релизы каждые полгода, выпуская маленькими партиями новый функционал. Если раньше можно было выбрать просто 8 версию, которая являлась LTS, и не прогадать с выбором, то теперь версий стало куда больше (на текущий момент уже 17). В связи с этим у многих новичков встает очевидный вопрос: как выбрать версию джавы? Может я просто возьму последнюю и все? Не совсем так, давайте разбираться.
Основным провайдером java является компания Oracle, которая предоставляет нам 2 типа jdk: OpenJdk и OracleJdk. Основное их отличие в том, что OracleJdk является платной и содержит в себе поддержку от самой компании (вы сможете им позвонить или написать письмо), если у вас возникнут какие-то проблемы. Такой вариант обычно необходим только очень большим продуктам и компаниям, поэтому мы его отбрасываем и будем пользоваться бесплатной версией. Скачать её можно тут – http://jdk.java.net
Теперь про версионность. Основной выбор всегда падает на LTS (Long Time Support) версии java, так как из-за долгой поддержки и исправления багов эти версии наиболее стабильны и преподносят меньшее число сюрпризов в продакшне. На текущий момент в мире все еще преобладает использование java 8, которая вышла в 2014 году. В основном это связано с тем, что на этой версии уже написаны крайне массивные продукты, которые потребуют больших трудозатрат и средств для переноса на более новые версии. А так как эти огромные продукты продолжают жить, то продолжает жить и java 8.
Для новых решений зачастую берется просто последняя LTS версия джавы. Да, вот так вот просто! До недавнего времени это была java 11, на текущий момент java 17. Но так как 17 версия все еще очень молодая (ей всего пару месяцев), я бы рекомендовал вам пока что выбрать 11 версию для изучения, так как не все еще основные инструменты и библиотеки успели переехать на новый релиз.
Также предлагаю вам посмотреть наикрутейшее выступление Тагира Валеева на JockerConf про то, как менялась java под капотом с 9 по 14 версию. https://youtu.be/5Y0Alqb9H_I
#rdclr_backend #java #read
Начиная с 2017 года релизная политика версий java в корне поменялась. Вместо продолжительных застоев в несколько лет с накоплением большого количества фич, было принято решение перейти на релизы каждые полгода, выпуская маленькими партиями новый функционал. Если раньше можно было выбрать просто 8 версию, которая являлась LTS, и не прогадать с выбором, то теперь версий стало куда больше (на текущий момент уже 17). В связи с этим у многих новичков встает очевидный вопрос: как выбрать версию джавы? Может я просто возьму последнюю и все? Не совсем так, давайте разбираться.
Основным провайдером java является компания Oracle, которая предоставляет нам 2 типа jdk: OpenJdk и OracleJdk. Основное их отличие в том, что OracleJdk является платной и содержит в себе поддержку от самой компании (вы сможете им позвонить или написать письмо), если у вас возникнут какие-то проблемы. Такой вариант обычно необходим только очень большим продуктам и компаниям, поэтому мы его отбрасываем и будем пользоваться бесплатной версией. Скачать её можно тут – http://jdk.java.net
Теперь про версионность. Основной выбор всегда падает на LTS (Long Time Support) версии java, так как из-за долгой поддержки и исправления багов эти версии наиболее стабильны и преподносят меньшее число сюрпризов в продакшне. На текущий момент в мире все еще преобладает использование java 8, которая вышла в 2014 году. В основном это связано с тем, что на этой версии уже написаны крайне массивные продукты, которые потребуют больших трудозатрат и средств для переноса на более новые версии. А так как эти огромные продукты продолжают жить, то продолжает жить и java 8.
Для новых решений зачастую берется просто последняя LTS версия джавы. Да, вот так вот просто! До недавнего времени это была java 11, на текущий момент java 17. Но так как 17 версия все еще очень молодая (ей всего пару месяцев), я бы рекомендовал вам пока что выбрать 11 версию для изучения, так как не все еще основные инструменты и библиотеки успели переехать на новый релиз.
Также предлагаю вам посмотреть наикрутейшее выступление Тагира Валеева на JockerConf про то, как менялась java под капотом с 9 по 14 версию. https://youtu.be/5Y0Alqb9H_I
#rdclr_backend #java #read
YouTube
Тагир Валеев — Java 9-14: Маленькие оптимизации
Подробнее о Java-конференциях:
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . . Мы видели много докладов об улучшениях в свежих версиях Java. Модули, var, неизменяемые коллекции, switch-выражения достаточно популярны…
— весной — JPoint: https://jrg.su/gTrwHx
— осенью — Joker: https://jrg.su/h7yvG4
— —
. . . . Мы видели много докладов об улучшениях в свежих версиях Java. Модули, var, неизменяемые коллекции, switch-выражения достаточно популярны…
Java. Какую версию выбрать? Часть 2
Помимо основного вендора java в лице Oracle, существуют и другие выпуски от других компаний. Давайте их рассмотрим:
🍒 1) AdoptOpenJDK
Проект, поддерживаемый сообществом. Команда выпускает билды, основанные на OpenJDK, отличие лишь в более долгосрочной поддержке. Команда занимается только билдами и не выпускает патчи для openjdk
🍩 2) Red Hat OpenJDK
Основана на версиях сборки OpenJDK, является коммерческим продуктом с платной поддержкой. В своих версиях компания нацелена на исправления безопасности в OpenJDK. В прошлом Red Hat отвечали за security-апдейты Java 6 и 7.
🫀 3) Azul Zulu
Основана на версиях OpenJDK, поставляется как open-source, но так же имеется — по сравнению с OracleJDK — более длительная коммерческая поддержка java 9, 13, 15.
🩱4) IBM JDK
Компании IBM требовалось написать свой собственный JIT-компилятор и свою собственную JVM, чтобы программы, написанные на java, могли запускаться на их мейнфреймах и при этом не заставлять разработчиков изучать новую java. Поэтому эти версии, с точки зрения программиста, практически идентичны.
🥡 5) Amazon Correto
Бесплатная версия сборки OpenJDK с долгосрочной поддержкой. Данная версия нацелена на максимальную производительность в облачных вычислениях. Так же Амазон каждый квартал выпускает багфиксы, что позволяет более оперативно устранять уязвимости.
🛺 6) Liberica JDK
Отечественная версия java, основанной также на OpenJDK. Плюсы перед OpenJDK все те же, что и других вендоров. Она бесплатна, более продолжительная коммерческая поддержка, частые выпуски обновлений безопасности, маленький размер контейнера (минимальный — всего 43.5мб).
Еще существенным плюсом является тот факт, что Liberica JDK Pro была внесена в реестр российского ПО. Это означает расширение диапазона применения Liberica JDK в государственных информационных системах, где крайне важна защита ПО от внешних факторов (например, санкций).
#rdclr_backend #java #read
Помимо основного вендора java в лице Oracle, существуют и другие выпуски от других компаний. Давайте их рассмотрим:
🍒 1) AdoptOpenJDK
Проект, поддерживаемый сообществом. Команда выпускает билды, основанные на OpenJDK, отличие лишь в более долгосрочной поддержке. Команда занимается только билдами и не выпускает патчи для openjdk
🍩 2) Red Hat OpenJDK
Основана на версиях сборки OpenJDK, является коммерческим продуктом с платной поддержкой. В своих версиях компания нацелена на исправления безопасности в OpenJDK. В прошлом Red Hat отвечали за security-апдейты Java 6 и 7.
🫀 3) Azul Zulu
Основана на версиях OpenJDK, поставляется как open-source, но так же имеется — по сравнению с OracleJDK — более длительная коммерческая поддержка java 9, 13, 15.
🩱4) IBM JDK
Компании IBM требовалось написать свой собственный JIT-компилятор и свою собственную JVM, чтобы программы, написанные на java, могли запускаться на их мейнфреймах и при этом не заставлять разработчиков изучать новую java. Поэтому эти версии, с точки зрения программиста, практически идентичны.
🥡 5) Amazon Correto
Бесплатная версия сборки OpenJDK с долгосрочной поддержкой. Данная версия нацелена на максимальную производительность в облачных вычислениях. Так же Амазон каждый квартал выпускает багфиксы, что позволяет более оперативно устранять уязвимости.
🛺 6) Liberica JDK
Отечественная версия java, основанной также на OpenJDK. Плюсы перед OpenJDK все те же, что и других вендоров. Она бесплатна, более продолжительная коммерческая поддержка, частые выпуски обновлений безопасности, маленький размер контейнера (минимальный — всего 43.5мб).
Еще существенным плюсом является тот факт, что Liberica JDK Pro была внесена в реестр российского ПО. Это означает расширение диапазона применения Liberica JDK в государственных информационных системах, где крайне важна защита ПО от внешних факторов (например, санкций).
#rdclr_backend #java #read
Микросервсиная архитекутера
Наверняка вы уже работали с приложением, построенным на микросервисах, а если нет, то слышали об этой архитектуре.
Можно взять и разбить приложение на микросервисы. Но это не даст гарантий, что проект будет легко поддерживать и масшабировать, гибко изменять код — рано или поздно вы столкнетесь с проблемами. Для решения таких проблем как раз и появились различные принципы программирования — SOLID, DRY, KISS, CQRS.
#rdclr_backend #Java
Наверняка вы уже работали с приложением, построенным на микросервисах, а если нет, то слышали об этой архитектуре.
Можно взять и разбить приложение на микросервисы. Но это не даст гарантий, что проект будет легко поддерживать и масшабировать, гибко изменять код — рано или поздно вы столкнетесь с проблемами. Для решения таких проблем как раз и появились различные принципы программирования — SOLID, DRY, KISS, CQRS.
#rdclr_backend #Java
👍4
Друзья, привет! На связи всё так же я, Павел, Java-разработчик Red Collar. 🤝
Решил потестить новый формат, чтобы текст легче воспринимался, а иллюстрации кода не терялись потом в поиске.
В общем, встречайте первую статью в Telegraph! Собрал здесь все принципы SOLID с примерами, подсветил сложные моменты, про всё рассказал подробно. 🦾
Читайте тут: https://telegra.ph/Open-closed--princip-otkrytosti--zakrytosti-05-16
#rdclr_backend #Java
Решил потестить новый формат, чтобы текст легче воспринимался, а иллюстрации кода не терялись потом в поиске.
В общем, встречайте первую статью в Telegraph! Собрал здесь все принципы SOLID с примерами, подсветил сложные моменты, про всё рассказал подробно. 🦾
Читайте тут: https://telegra.ph/Open-closed--princip-otkrytosti--zakrytosti-05-16
#rdclr_backend #Java
Telegraph
SOLID
Роберт С. Мартин сформулировал 5 принципов ООП: 🖐🏻 - Single Responsibility - Open-closed - Liskov substitution - Interface segregation - Dependency Inversion Данные принципы помогают избавиться от плохого кода, оптимизировать его и создавать гибкие приложения…
👍5
Друзья, всем привет! Это вновь я, Java-разработчик Red Collar Павел.
Продолжаю тестить Телеграф и рассказывать вам о фишках разработки. На этот раз — о Spring DATA JDBC.
Это классная альтернатива JPA, но у неё, конечно, есть свои подводные камни.
Читайте о них здесь: https://telegra.ph/Spring-DATA-JDBC-05-24
#rdclr_backend #Java
Продолжаю тестить Телеграф и рассказывать вам о фишках разработки. На этот раз — о Spring DATA JDBC.
Это классная альтернатива JPA, но у неё, конечно, есть свои подводные камни.
Читайте о них здесь: https://telegra.ph/Spring-DATA-JDBC-05-24
#rdclr_backend #Java
Telegraph
Spring Data JDBC
⚡️ В 2018 году разработчики Spring Data представили альтернативу JPA — Spring Data JDBC. Она стремится быть концептуально проще по трём критериям: 1) Никаких ленивых загрузок или кеширования. При получении сущности, она загружается сразу, как только выполняется…
🔥16👍1