Инверсия управления

Одним из наиболее значимых принципов объектно-ориентированного программирования является инверсия управления или принцип инверсии управления. Так же этот принцип в шутку назван «Голливудским принципом», смысл которого раскрывается в определении: «Не звоните нам, мы сами вам позвоним». Данный принцип позволяет существенно снизить связанность между компонентами программного обеспечения, а также изменить процесс его разработки таким образом, чтобы сторонние фреймворки могли использовать компоненты, разрабатываемые другими разработчиками.

Если мы представим себе процесс разработки какого-нибудь проекта, например REST-сервиса, с чистого листа без использования каких-либо фреймворков, то выглядеть он будет следующим образом. Первым делом мы реализуем HTTP-сервер, который будет принимать входящие запросы и маршрутизировать их в компоненты, способные их обработать.

Однако давайте зададим себе вопрос: «А когда в последний раз мы писали собственный HTTP-сервер для REST-сервиса?», наверняка большинство из вас ответит: «Никогда!». Вместо этого мы используем какие-то готовые решения для обслуживания HTTP-запросов, к которым относятся Java EE/Jakarta EE Servlet API, Netty, Spring Framework, Helidon, Micronaut и многие другие фреймворки. Таким образом мы отдаём контроль над потоком исполнения кода сторонним фреймворкам, разрабатывая только специфичные для наших задач компоненты, которые должны быть использованы фреймворками. Именно в передаче контроля над потоком исполнения кода фреймворкам является инверсией управления: фреймворки управляют исполнением кода нашего приложения, а не приложение управляет фреймворками.

Основными способами реализации инверсии управления являются шаблоны проектирования «Шаблонный метод», «Стратегия» и «Локатор служб». Так Servlet API реализует как раз шаблон проектирования «Стратегия», предоставляя интерфейс Servlet, в реализации которого разработчик может разместить свой код для обработки HTTP-запроса. Spring Framework и проекты, входящие в экосистему Spring, тоже широко используют шаблон проектирования «Стратегия»: в интерфейсе HandlerFunction — для обработки HTTP-запросов в функциональном стиле, в UserDetailsService — для получения информации об аутентифицирующемся пользователе и т.д.

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

Внедрение и поиск зависимостей

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

Под инверсией управления понимается подход к написанию кода, при котором элементы кода получают поток управления неявно от некоторого фреймворка. Иными словами, если сравнивать с традиционным процедурным программированием, не код обращается к фреймворку или библиотекам для выполнения какого-либо действия, а наоборот, фреймворк обращается к нашему коду.

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

Шаблон проектирования декоратор

Во второй статье цикла, посвящённого шаблонам проектирования, я хотел бы поговорить про шаблон проектирования «декоратор», который я частенько путаю с шаблоном «адаптер». О последнем, кстати, я подробно рассказывал в предыдущей статье. Впрочем, оба шаблона проектирования делят одно альтернативное название — «обёртка» (Wrapper).

Читать далее Шаблон проектирования декоратор

Шаблон проектирования адаптер

При написании материалов я так или иначе касаюсь темы шаблонов проектирования, однако я обратил своё внимание на то, что нередко путаюсь в их названиях. Поэтому я решил перечитать книгу «банды четырёх», а заодно написать цикл материалов по шаблонам проектирования с примерами кода на языке программирования Java.

Открывает цикл материалов статья о шаблоне проектирования «адаптер». Адаптер, так же известный как «обёртка» (wrapper), применяется в тех случаях, когда некоторый существующий класс необходимо адаптировать под использование с другим целевым интерфейсом без внесения изменений в адаптируемый класс, дабы не нарушать принцип открытости/закрытости.

Читать далее Шаблон проектирования адаптер

SOLID в деталях: Принцип открытости/закрытости (Видео)

В серии роликов «SOLID в деталях» я постараюсь подробно рассказать о принципах SOLID, а так же продемонстрировать их практическое применение.

Второй ролик посвящён принципу открытости/закрытости.

SOLID в деталях: Принцип подстановки Лисков

Третьим принципом в списке SOLID является Принцип подстановки Лисков (Liskov Substitution Principle; LSP), который из всех принципов имеет самую сложную формулировку, звучащую следующим образом:

Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

Барбара Лисков
Читать далее SOLID в деталях: Принцип подстановки Лисков

SOLID в деталях: Принцип единственной ответственности (Видео)

В серии роликов «SOLID в деталях» я постараюсь подробно рассказать о принципах SOLID, а так же продемонстрировать их практическое применение.

В первом ролике речь пойдёт о принципе единственной ответственности (Single Responsibility Principle; SRP), его трактовках и их практическом применении.

Видео можно посмотреть на следующих платформах:

Текстовая версия видео

Spring JDBC в деталях: SimpleJdbcInsert

Решил я проанализировать источники трафика на моём сайте и обнаружил, что на сайт частенько заходят в поисках информации о SimpleJdbcInsert, о чём я толком не рассказывал. Поэтому этой статьёй я постараюсь закрыть этот пробел.

SimpleJdbcInsert — один из вспомогательных инструментов, предоставляемых Spring Framework JDBC для работы с реляционными базами данных, задача которого — предоставить удобный механизм для вставки новых строк в таблицы.

Читать далее Spring JDBC в деталях: SimpleJdbcInsert

Карьерный путь сельского джависта

Приключение на двадцать минут

Наверняка я не ошибусь, если предположу, что многие, задумываясь о карьере программиста, думают, что купят пару-тройку книг по языку программирования, прочитают их, пройдут пару курсов и начнут покорять IT-олимп. Во всяком случае одним из таких людей когда-то был я.

Читать далее Карьерный путь сельского джависта

SOLID в деталях: принцип открытости/закрытости

Принцип открытости/закрытости (Open-Closed Principle; OCP), на мой взгляд, является главным принципом в списке принципов SOLID, в то время как все остальные в той или иной мере обеспечивают его соблюдение. Этот принцип сформулировал Бертран Мейер в своей книге «Object-Oriented Software Construction» в 1988 году следующим образом: «Программные сущности (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для изменения» (Software entities (classes, modules, functions, etc) should be open for extension, but closed for modification). Иными словами, должна иметься возможность изменять поведение программных сущностей без их изменения, как написал Роберт Мартин в книге «Чистая архитектура».

Читать далее SOLID в деталях: принцип открытости/закрытости