SOLID на практике — принцип инверсии зависимостей

Принцип инверсии зависимостей (Dependency Inversion PrincipleDIP, буква D в аббревиатуре SOLID), описанный Робертом Мартином, состоит из двух постулатов:

  • Высокоуровневые модули не должны зависеть от низкоуровневых; и те и другие должны зависеть от абстракций
  • Абстракции не должны зависеть от деталей, детали должны зависеть от абстракций

Инверсия зависимостей заключается в том, что модули разных уровней зависят не друг от друга, а от абстракций. В общих чертах принцип инверсии зависимостей сводится к следующему набору простых правил:

  • Взаимодействие между классами должно быть реализовано через интерфейсы или абстрактные классы
  • Типами всех членов классов должны быть интерфейсы или абстрактные классы
  • Классы, являющиеся конечными реализациями не должны расширяться (или должны быть финальными)
  • Аналогично методы не должны перекрываться при наследовании (или быть финальными)

Читать далее SOLID на практике — принцип инверсии зависимостей

Spring Security OAuth 2.0 и Apereo CAS

Фреймворк Spring Security позволяет реализовать авторизацию в приложении при помощи протокола OAuth 2.0. Провайдерами авторизации могут быть как общедоступные сервисы, вроде Google, Facebook или GitHub, так и персональные, реализованные, например, при помощи Apereo CAS.

Читать далее Spring Security OAuth 2.0 и Apereo CAS

SOLID на практике — принцип единственной ответственности

Принцип единственной ответственности (Single Responsibility Principle — SRP, буква S в аббревиатуре SOLID), описанный Робертом Мартином, гласит: «Класс должен иметь только одну причину для изменения».

Обратите внимание на следующий код:

В примере приведён метод сохранения изменений в записи типа Topic. Однако этот метод выполняет слишком много действий: валидацию полученных данных, поиск существующего объекта типа Topic, проверку прав доступа пользователя на этот объект, применение и сохранение изменений. И все эти действия могут меняться независимо друг от друга.

Следуя логике принципа единственной ответственности, нам следует выделить работу с источником данных, валидацию и проверку прав доступа, как минимум, в отдельные методы, а наиболее правильно — в отдельные классы.

Выделение логики в отдельные методы

В первом варианте мы разделим логику между методами класса TopicService. Кроме этого данные, получаемые методом update, логично будет инкапсулировать в одном классе:

В результате выделения логики валидации, работы с источником данных и проверки прав доступа в отдельные методы должен получиться примерно такой код:

Теперь этот код на уровне методов соответствует принципу единственной ответственности, чего не скажешь о всём классе TopicService. Не смотря на то, что методы findOneById, save, checkAccess и validate скрыты от внешнего наблюдателя, класс всё равно выполняет много действий.

Однако даже при этом код уже более удобен для понимания, а так же пригоден для повторного использования.

Выделение логики в отдельные классы

При выделении логики валидации, проверки прав и работы с источниками данных в отдельные классы, код приложения станет ещё удобнее и понятнее.

Таким образом мы получим класс, работающий с источником данных:

Класс, выполняющий валидацию UpdateTopicAction:

Класс, проверяющий доступ пользователя к объекту Topic:

Итоговый вид нашего сервиса будет следующим:

Таким образом мы на практике применили принцип единой ответственности.

Spring Restdocs and Spring Cloud Contract with Cucumber and Spring Webflux

In this post, I will describe Spring Restdocs and Spring Cloud Contract integration into Cucumber tests with Spring Webflux. The main problem is that we can’t use the most of common JUnit and Spring Test annotations like @Before, @After and @Rule in Cucumber tests, so we have to set up testing environment manually. This post is a webflux adaptation of the previous post.

Читать далее Spring Restdocs and Spring Cloud Contract with Cucumber and Spring Webflux

Spring Restdocs and Spring Cloud Contract with Cucumber

In this post, I will describe Spring Restdocs and Spring Cloud Contract integration into Cucumber tests. The main problem is that we can’t use the most of common JUnit and Spring Test annotations like @Before, @After and @Rule in Cucumber tests, so we have to set up testing environment manually.

Читать далее Spring Restdocs and Spring Cloud Contract with Cucumber

Интеграционное тестирование REST API с Cucumber, Spring Restdocs и Spring Cloud Contract

Модульные и интеграционные тесты серьёзно упрощают жизнь простого разработчика, позволяя выявить большую часть ошибок и проблем ещё на ранних стадиях разработки. Отдельного упоминания заслуживают фреймворки Spring Restdocs и Spring Cloud Contract, использование которых в интеграционных тестах позволяет сгенерировать сниппеты, заглушки и контракты тестируемых REST API.

Читать далее Интеграционное тестирование REST API с Cucumber, Spring Restdocs и Spring Cloud Contract

Разработка приложений со Spring. Базовое веб-приложение.

В данной статье я рассмотрю процесс разработки простого веб-приложения с использованием Spring и Thymeleaf. Данный проект будет использоваться в последующих статьях, в рамках которых приложение будет описано дальнейшее развитие приложения. Исходный код проекта доступен по этой ссылке.

Читать далее Разработка приложений со Spring. Базовое веб-приложение.

Spring Data JPA: Волшебные методы

В предыдущем посте я вкратце рассказал о Spring Data JPA и затронул тему «волшебных» методов, приведя простой пример их использования. Однако возможности волшебных методов значительны, благодаря чему ими можно заменить именованные запросы в большинстве случаев.

Читать далее Spring Data JPA: Волшебные методы

Spring Framework и работа с базами данных: Spring Data JPA

В предыдущих постах о работе с базами данных в Spring Framework я поверхностно описал использование JdbcTemplate и NamedParameterJdbcTemplate. Пользоваться данными инструментами безусловно удобно, но у них есть определённые ограничения, среди которых:

  • Зависимость SQL-запросов от конкретной СУБД
  • Необходимость в самостоятельной реализации преобразования данных из БД в экземпляры классов-сущностей
  • Увеличение и усложнение кода при появлении новых таблиц и столбцов в таблицах

В стеке Spring существует проект Spring Data, реализующий большую часть тривиальных задач и упрощающий работу с источниками данных. В качестве источников данных могут использоваться как стандартные реляционные базы данных, так и NoSQL-хранилища вроде MongoDB или Redis.

Читать далее Spring Framework и работа с базами данных: Spring Data JPA

Коротко о PathVariable

Один из распространённых способов передачи параметров запроса — в виде частей адреса запроса. Например, у нас есть страница с контактными данными человека, её адрес выглядит следующим образом:

http://example.com/person/contacts?personId=42

Но, если передать идентификатор человека не параметром personId, а частью адреса запроса, то получится что-то вроде

http://example.com/person/42/contacts

Что выглядит намного понятнее и удобнее.

Для работы с параметрами, передаваемыми через адрес запроса в Spring WebMVC используется аннотация @PathVariable. Читать далее Коротко о PathVariable