Одна маленькая ошибка в дизайне Java API, за которую потом приходится платить очень дорого

Вот важная новость с фронта ИИ: mipo256 1 час назад Одна маленькая ошибка в дизайне Java API, за которую потом приходится платить очень дорого Средний 5 мин 719 Блог компании Spring АйО Java * Программирование * Кейс Привет, Друзья! Хотел написать короткий пост по мотивам одного казалось бы простого ПР-а, который мы недавно получили в рамках Axelix: Open Core продукта для решения основных известных болей при разработке Spring Boot приложений (кстати, give us a star! В общем, контрибьютор пришёл к нам и исправил с виду совершенно безобидную проблему, которую мы упустили.

Но на деле, эта проблема со временем могла привести к другим багам, которые дебажить было бы крайне тяжело. И я посчитал, что это стоит небольшой статьи, потому что сам помню проблемы в Spring Data, которые возникали из-за подобных просчётов. Я не буду погружать вас в детали того, что мы делали, просто покажу на абстрактном примере.

Технические детали

Давайте с места в карьер. Посмотрите на этот код:public class SeeminglyGoodCache { private final Map internalCache = new HashMap<>(); public void put(String key, Object value) { internalCache. put(key, value); } public Object get(String key) { return internalCache.

get(key); } public Map getCache() { return this. internalCache; } } Для упрощения ситуации, предположим, что мы выносим concurrency из уравнения - предположим однопоточное приложение. Пример намеренно сделан максимально тупым и наглядным.

Видите ли вы в коде выше какие-то проблемы? На деле проблем тут несколько, но есть одна, про которую я и хочу поговорить. У неё нет чётко устоявшегося названия, но заключается она в том, что метод getCache() возвращает ссылку на внутреннее изменяемое состояние объекта.

Отраслевые последствия

На деле схожая ситуация и с методом get(), но getCache() сейчас гораздо важнее. Потому что текущий код позволяет взять и мутировать состояние кеша извне. Уже это само по себе влечет за собой 2 неприятности:1.

Сломанная ИнкапсуляцияКогда человек начинает изучать ООП языки программирования, то инкапсуляция это одна из первых вещей, которую он слышит. Это реально важная штука, потому что несоблюдение инкапсуляции логики/состояния/complexity приводит к плохим последствиям. У нас есть чёткое понимание, что есть слой работы с БД, и слой API никогда не будет ходить к БД в обход этого слоя.

И за счёт этого на слое работы с БД мы можем накручивать различного рода аудит события (например, hibernate-envers). Мы также можем накручивать multi-tenancy (для SaaS архитектуры например) и т. И мы можем быть уверены, что любой доступ к бд будет аудирован.

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