Чем отличаются Dependency injection, Dependency invertion и Inversion of Control

Прошлый пост про Liskov, как говорится, "взорвал мой директ", поэтому на этой неделе расскажу про ещё два популярных принципа.

Сегодня про букву D из SOLID — Dependency Inversion. Что это, и чем отличается от Dependency injection и Inversion of Control. Понимание пригодится на собеседованиях, при чтении статей по дизайну и архитектуре.

Будем разбираться на простом примере: класс Service записывает логи в файл через класс FileLogger:

class FileLogger {…}
class Service {
  FileLogger logger=new FileLogger();
}

Сделаем код чуть лучше с помощью разных принципов:

1️⃣ Dependency injection
— компоненты создаются не внутри класса, а где-то в другом месте.

Как реализовать: перенести инициализацию логгера в конструктор или сеттер:

class Service {
  FileLogger logger;
  Service (FileLogger logger) {
    this.logger=logger;
  }
}

✅ Класс занимается только своей бизнес-логикой
✅ Можно вынести всю конфигурацию в одно место. Или спихнуть часть забот фреймворку, например, Spring

⚔️Историческая справка
Когда Spring ещё не был популярен, в проектах использовался паттерн Service Locator.

Суть: компоненты создаются в классе ServiceLocator, а другие классы получают к ним доступ через статические методы:

class ServiceLocator {
  static Logger logger = …
  static Logger getLogger() {
     return logger;
  }
}

class Service {
  Logger logger=ServiceLocator.getLogger();
}

2️⃣ Dependency invertion (D из SOLID)
▫️Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций
▫️Модули верхнего уровня не должны зависеть от модулей нижнего уровня. Оба должны зависеть от абстракции

Как реализовать: использовать интерфейс логгера, а не конкретный класс

interface Logger {…}
class FileLogger implements Logger {…}

class Service {
   Logger logger=new FileLogger();
}

✅ Интерфейс проще использовать, так как методов меньше
✅ Реализацию легко заменить
✅ Оба класса проще тестировать

Термин "абстракция" используется, потому что SOLID не привязан только к джаве. Группу методов можно выделить в интерфейс, в абстрактный класс и даже в обычный класс. Но интерфейс — наилучший вариант

3️⃣ IoC - Inversion of Control
В маленьких программах жизнь начинается в методе main. Программист создаёт объекты и вызывает их методы, все шаги явно прописаны.

Inversion of Control — это когда ход выполнения программы задаёт фреймворк. Например, Spring создаёт объекты, принимает запросы и не даёт программе завершиться.

Как реализовать: использовать аннотации фреймворка

@Component class FileLogger {…}
@Component class Service {
  @Autowired
  FileLogger logger;
}

✅ Меньше скучного кода
✅ Низкая связность — код легко читать, менять и тестировать

Резюме:
🔸Dependency injection — класс не создаёт компоненты напрямую, они передаются через конструктор или сеттер
🔸Dependency invertion — класс работает с другими компонентами через интерфейс
🔸Inversion of Control — ход программы задаёт фреймворк

❗️Ответ на вопрос перед постом:
Это словоблудие относится к Dependency injection

DRY для джуниора и сеньора

Раз уж пошли по базовым принципам, то сегодня разберём DRY: Don't Repeat Yourself.

Такой популярный и такой обманчиво простой.

Отношение к DRY эволюционирует по мере роста разработчика и проходит через четыре этапа:

🔸 Этап 1. Стажёр

Боготворит DRY, считает дублирование кода ужасным грехом. Действительно, зачем писать несколько раз одно и то же?

Для этого код максимально оптимизируется. Универсальные методы, универсальные статические методы, много входных параметров.

🔸 Этап 2. Джуниор

Любит DRY, но понимает, что любить — значит страдать.

Проект становится больше, а бизнес-логика — сложнее. Добавить в метод ещё один if уже не так просто. Сложно разбираться в коде, сложно писать тесты, но чего не сделаешь ради хорошего кода. А хороший код на этом этапе — это максимально сжатый код🙂

🔸 Этап 3. Мидл

Всё ещё любит DRY, но более возвышенно — на уровне иерархий и паттернов. Когда приходится дублировать код, то грустит, что на проекте плохая архитектура.

🔸 Этап 4. Сеньор

Распилил монолит на сервисы, реализовал десятки крупных фич и отдал сердце SOLID.

А теперь по делу

Часто начинающие разработчики считают, что хороший код — это суперконцентрированный код с кучей паттернов и хитрых приёмов.

В больших проектах хороший код — это тот, который легко читать, тестировать и поддерживать. Оптимизации и приёмчики - это совсем небольшая часть кодовой базы.

Если бизнес-процессы не пересекаются, то связывать их искусственно с помощью кода — плохая идея.

🙁 Класс User c 20 полями. 10 полей используются в 1 сервисе, другие 10 - в другом, половина объекта всегда пустая
🙁 Универсальный метод с 7 параметрами под разные случаи
🙁 Сложная иерархия с кучей шаблонных методов

Единственный плюс — меньше кода. Зато
❌ Плохая читаемость
❌ Сложно писать тесты
❌ Сильная связность. Функцию тяжело поменять или вынести в другой модуль

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

Что такое Serverless. Часть 1: предыстория

По статистике 2021 года около 10% проектов уже используют архитектуру Serverless.

Новые технологии — это классно, но важно понять, в чём вообще проблема и как она УЖЕ решается текущими средствами. И зачем решать её по-новому. Нужен чёткий ответ:

— Зачем переходить с микросервисов на Serverless? Что мы от этого получим?

Для ответа немного углубимся в историю инфраструктуры.

1️⃣ Всё своё

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

❌ Много расходов на оборудование и персонал
❌ Железки надо закупать, подключать и нельзя сдать обратно. Сложно наращивать мощности или оптимизировать нагрузку

2️⃣ IasS — Infrastructure as a Service

В 2006 появился Amazon EC2 и начался тренд на IaaS: код запускается не на собственных серверах, а на арендованных.

Это самый простой вариант облачной инфраструктуры. Сейчас подобную услугу предлагают AWS, Google, DigitalOcean, Microsoft, IBM, SAP, для патриотов есть Яндекс и Сбер.

✅ Легко добавлять и сокращать ресурсы
✅ Меньше расходы на персонал
✅ Не надо беспокоиться об отключении электроэнергии и потопах

Инфраструктура всё ещё требует внимания — на арендованной виртуалке надо установить ОС, JVM, все службы и обновления, настроить компоненты и развернуть сервисы.

Большая часть этих операций почти у всех одинакова. Так что дальше расходимся на две ветки:

🅰️ PaaS — Platform as a Service

PaaS = IaaS + ОС + базовый мониторинг + легко подключаемые компоненты

Облачные провайдеры берут на себя больше рутинных операций. Выглядит как будто работаешь с удалённой машиной. Можно довольно легко добавить БД, мониторинг, кэши, очереди и связать их между собой в настройках.

Примеры PaaS: Heroku, AWS Elastic Beanstalk и тд

✅ Много готовых компонентов — можно быстро настроить работающую систему
❌ Набор компонентов большой, но всё же ограниченный. Если использовать что-то непопулярное, то придётся искать обходные пути
❌ Сильная привязка к вендору. Выбрал PaaS от амазона — скорее всего файловое хранилище, очереди и БД тоже будут амазон.

🅱️ Докер

Популярная альтернатива PaaS — докер-контейнеры в предоставленных виртуалках. В каждом контейнере свой runtime и все нужные для сервиса файлы.

Для управления контейнерами есть куча инструментов — Kubernetes, Mesos, Google Container Engine. Amazon ECR и Google CR помогают с хранением докер-образов, AWS Fargate — с масштабированием.

✅ Супер гибкость. Можно собрать любые компоненты с любыми настройками и связать их как угодно
❌ Cложно выбирать и долго настраивать

Заметили, что не было ни единого слова про архитектуру? PaaS и Docker только упрощают сборку инфраструктуры. Пока что нет разницы, что запускать внутри — гигантский монолит или сервис из трёх файлов.

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

Что такое Serverless, часть 2

В прошлом посте рассмотрели, как инфраструктура понемногу переходила на аутсорс. Serverless — следующий этап такого перехода.

AWS Lambda — самая первая и популярная платформа для Serverless, поэтому дальше буду говорить про неё.

Важно! Есть ещё термин Lambda Architecture — это вообще про другое.

Итак, в чём суть.

Любое приложение — это набор функций. Допустим, в интернет-магазине три функции:
▫️ Добавить товары
▫️ Сделать заказ
▫️ Вывести список текущих заказов

Можно запихать всё в один артефакт — получится монолит. Можно каждую функцию обернуть в отдельный сервис — получатся микросервисы.

Serverless абстрагируется от этой проблемы. Мы не распределяем функциональность по артефактам и работаем просто с функциями. Проектируем не сборник фич, а отдельные маленькие компоненты.

Поэтому Serverless считается архитектурой. Или отдельной моделью проектирования, если термин "архитектура" кажется вам неподходящим.

Платформы, на которых запускаются Serverless приложения, называют FaaS — Functions as a Service.

В Петербурге Serverless используют около 10 компаний, что не очень много. Но тренд растёт, даже Сбер уже сделал свою FaaS платформу.

Как это работает?

Каждая функция состоит из:
▫️ Исполняемого кода
▫️ Списка зависимостей
▫️ Списка событий-триггеров
▫️ Конфигурации — количество памяти, необходимые права, время жизни функции и тд

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

Станет ли код проще?

Точно нет. Проектировать систему с изолированными функциями гораздо сложнее, чем слепить всё в монолит или десяток сервисов🙂

У Serverless свой деплой, тестирование и кодовая база. Даже если перенести только некоторые части приложения, общая схема заметно усложнится.

Зачем переходить на Serverless?

Если микросервисы в PaaS или докере нормально справляются, то должна быть веская причина что-то менять. Таких причин может быть две:

1️⃣ Функции развёртываются по необходимости. Облака это удобно, но иногда очень дорого. FaaS модель неплохо снижает стоимость при переменной нагрузке.

2️⃣ Масштабирование по умолчанию. В AWS Lambda автоматически масштабируются и сервисы, и остальные компоненты, например, БД. В докере и PaaS для этого нужно прилагать немало усилий.

Сколько стоит?

Допустим бэкенд мобильного приложения принимает за месяц 3 миллиона запросов, среднее время — 120мс. Выделим для одной функции 1536 МБ и процессор х86.
Плата за месяц в таком случае будет 2,7 доллара.

Это только AWS Lambda, остальные компоненты оплачиваются отдельно.

Что ещё

✅ Никаких Ansible, Docker, bash скриптов
✅ Базовый мониторинг и аналитика из коробки
✅ Spring Cloud и плагин IDEA AWS Toolkit сильно облегчают разработку

😐 Нужны отличные навыки проектирования
😐 Своеобразное тестирование

❌ Сложно адаптировать уже существующие приложения
❌ Больше задержек, response time может увеличиться

В целом Serverless — очевидный тренд, который набирает обороты. Жду в ближайшие два года тонну докладов на конференциях на эту тему, как когда-то было про микросервисы и реактивное программирование🙂

​Сколько объектов Number[] будет создано в этом коде?

Enum и метод values

Если вы новичок и мало знаете про enum, то лучше начать с этого лонгрида. Сегодня обсудим итерацию через метод values и как его оптимизировать.

Итак, enums — это синтаксический сахар, который при компиляции превращается в обычный класс. Класс из примера выше превратится в

public final class Number extends Enum<Number

>

Элементы енума станут статическими полями:

public static final Number ONE;
public static final Number TWO;
public static final Number THREE;

Внутри нового класса появится массив:

Number[] VALUES = { ONE, TWO, THREE};

И его копия будет возвращаться в методе values:

return VALUES.clone();

При каждом вызове values возвращается новая копия массива. Дело в том, что массивы — это изменяемый объект. Если возвращать ссылку на VALUES напрямую, любой желающий сможет поменять исходный массив:

Number.values()[2] = ONE;

Это небезопасно, поэтому каждый раз возвращается копия.

Если цикл с values используется в высоконагруженном коде, то разумно сохранить массив в отдельную переменную и переиспользовать её:

static Number[] numbers = Number.values();

for (Number n : numbers) {…}

Если код вызывается редко, то смысла в отдельной переменной нет.

Пример из жизни

В Spring Web 5.2 в классе HttpStatus есть такой код:

for (HttpStatus status : values()) {
  if (status.value == statusCode) {
    return status;
  }
}

Этот цикл вызывается почти в каждом запросе, но только в этом году завели баг. К описанию прилагался бенчмарк: при нагрузке 600 запросов/сек код производил мегабайт мусора каждую секунду.

Теперь код выглядит так:

private static final HttpStatus[] VALUES;

static {
  VALUES = values();
}

for (HttpStatus status : VALUES) {
  if (status.value == statusCode) {
    return status;
  }
}

Ответ на вопрос перед постом

Будет создано 3 массива: один внутри класса Number и два клона при вызове values()

Потихоньку появляются доклады с Joker 2021. Конференции - это классно, но часто бывает, что:

▪️ Название доклада не отражает содержание
▪️ Тема интересная, но слушать тяжело
▪️ Доклад слишком простой или слишком сложный

Поделюсь с вами summary двух самых популярных докладов с последнего джокера.

Выделила основные идеи, полезные детали и сгруппировала всё, что получилось. Если тема заинтересует — посмотрите целиком. Если нет — сэкономите 2 часа жизни🙂

P.S. Все вопросы по содержанию не ко мне, а к спикерам

Два доклада с Joker 2021

1️⃣ Алексей Нестеров, Олег Докука — Что нового в Spring Framework 6 (1:10:58)

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

Spring 6 использует java 17 и не будет работать на версиях ниже.
Дата выхода - октябрь 2022.
Кодовая база Spring 6 использует модули (фича java 9). Можно скомпилировать только нужные модули, и итоговый проект займёт меньше места.

Spring Native переедет в Spring Boot 3.
Spring будет связывать некоторые бины на этапе сборки, а не в рантайме. Это ускорит запуск приложений и потребление памяти.

Поменяются имена некоторых модулей. Например, пакет javax.* станет jakarta.*
В Spring WebFlux добавится поддержка HTTPClient из JDK 11.

Что удалится: Hessian, Http Invoker, JMS Invoker, JAX-WS, SecurityManager.

Что удалится, но менее вероятно: поддержка Joda Time, RxJava 1/2, FactoryBean, Autowired через сеттеры, конфигурация через XML.

Зачем смотреть: незачем. Информация недостоверная, много догадок, мало деталей.

2️⃣ Иван Крылов — От 11 к 17 версии Java (55:07)

Это доклад НЕ про новые фичи языка. Про sealed классы, records и switch спикер отсылает на доклад Тагира Валеева Java 17 для тех, кто в танке.

Два подхода к обновлению версии java в проекте:

1) Каждые полгода переходить на новую версию

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

Плюс — всегда новая и поддерживаемая версия java
Минус — раз в полгода тратить несколько спринтов на переход

2) Переходить только на LTS версию

Встречается в проектах с редкими релизами — реже, чем раз в полгода.
Минус — переход всегда долгий и трудный, оттягивается до последнего.

Переезд на java 17 — это необходимость. Дело не в новых фичах, а в том, что поддержка старых версий ограничена и периодически прекращается. Миграция с 8 до 17 сложная, с 11 до 17 попроще.

С чем могут быть проблемы при переходе

▫️ Удалены финалайзеры из FileOutputStream, FileInputStream, zip.Deflater, zip.Inflater, zip.ZipFile, color.ICC_Profile. Это связано с предстоящим удалением финалайзеров в java 18.
▫️ Удалён конструктор URLDecoder.
▫️ Многие классы в AWT и Swing поменяли видимость.
▫️ Удалён Applet API.

Изменения виртуальной машины

▪️ GraalVM больше не связан с OpenJDK. Причина — административные проблемы и сложности с версионированием относительно OpenJDK.
▪️ Удалена оптимизация biased locking из-за плохой совместимости с Project Loom.
▪️ Добавлены CDS архивы для уменьшения времени старта VM.
▪️ Гибкий metaspace.

Изменения в сборщиках мусора

▫️ Удалён CMS.
▫️ ZGC готов к использованию в продакшене с 15 версии, в ранних версиях очень много багов.
▫️ G1 и Shenandoah возвращают неиспользуемую память ОС. Это уменьшает потребляемую память сервиса, и сервисы в облачной среде обойдутся дешевле.

Изменения в JDK

▪️ Классы по работе с TCP и UDP работают быстрее — DatagramSocketAPI, SocketAPI.
▪️ NullPointerException показывают больше информации.
▪️ Новый генератор случайных чисел.

Изменения Security

▫️ Добавлены Root сертификаты с разным сроком действия
▫️ Удалён SecurityManager
▫️ Удалены модули java.security, java.rmi.activation

Платформы

▪️ Добавилась поддержка Linux Alpine. ОС полезна для маленьких контейнеров в облаках. В ОС меньше команд, поэтому она более безопасна. Если маленькие контейнеры не нужны, то лучше выбрать другую ОС.
▪️ Полная поддержка ARM: унифицированный Linux порт, Windows, macOS

Какие проекты не успели войти в java 17

▫️ Loom: легковесные потоки в JVM
▫️ Panama: работа с нативным кодом, альтернатива JNI
▫️ Valhalla: новые типы данных value types — функциональные как классы и компактные как примитивы

Зачем смотреть: незачем. Большую часть видео перечисляются неязыковые фичи между 11 и 17 версией. О них говорят редко, так что для кого-то информация окажется новой. Но с тем же успехом можно посмотреть полный список фич и поискать слова, которые актуальны для вашего проекта или интересны лично вам.

State of spring 2021

Поделюсь статистикой State of spring 2021 от VMWare. Данные релевантны для энтерпрайзных проектов из Европы и США.

Сама статистика довольно скучная, поэтому дам небольшое овервью по некоторым модулям.

🔸 79% используют Spring Security в рабочих проектах

🔸 79% Spring Data

Простые интерфейсы для работы с данными из разных БД. Обычно используется в связке с:
▫️ 78% JPA
▫️ 74% JDBC
▫️ 46% MongoDB
▫️ 37% Redis
▫️ 31% ElasticSearch

🔸 73% WebMVC
🔸 61% Boot
🔸 39% Kafka

🔸 38% Batch — фоновая обработка большого количества данных

🔸 37% Cloud

Не смотрите на название, модуль используется не только в облачной инфраструктуре.

Берёт на себя типовые задачи в микросервисной архитектуре:
▫️ Service Discovery — получить адрес другого сервиса
▫️ Добавить в логи информацию про конкретный сервис

🔸 35% WebFlux — поддержка реактивных библиотек

🔸 32% Integration

Ещё один уровень абстракции и набор готовых компонентов, которые соединяются через Enterprise Integration Patterns. Через конфигурацию можно описать несложную логику вроде "прочитай XML, преврати в JSON, отправь по HTTP".

🔸 3% Native

Компиляция и запуск на GraalVM. Уменьшает время старта и потребление памяти, хорошо работает с контейнерами.
Большинство опрошенных в восторге от Native, но пока не торопятся внедрять в рабочий проект. Потому что Native пока в стадии бета и GraalVM слишком незрелая технология. Но 65% планируют использовать Native в будущем.

Мой вариант — последний😊 Чищу мандаринки, смотрю статистику канала и радуюсь.

Спасибо, что читаете нудные посты без картинок, помогаете найти ошибки и задаёте интересные вопросы. Благодаря вам канал живёт и развивается!

Продолжим этот движ в 2022🚀

Гороскоп на 2022

Хороший год начинается с астрологического прогноза.

Если ваши спринты по две недели (половина лунного цикла), а сервисы развёртываются в облаках, то этот небесный прогноз для вас.

♈️ Овен (21 марта — 20 апреля)

В этом году возможен большой шаг в карьере, но он не будет простым. Откажитесь от лишней эмоциональности и просто идите в выбранном направлении. Посмотрите книгу Программист-прагматик, там для вас есть дельный совет.

♉️ Телец (21 апреля — 20 мая)

Год будет богат на свежие идеи и начинания. Начните то, что давно откладывали, расширяйте кругозор и пробуйте новое. Обязательно делайте бэкапы и резервные копии.

Поездите по России, вам понравится. Петербург, Краснодар, Кисловодск, Байкал, Алтай, Кавказ🧡

Во второй половине года порадуйте себя новой техникой.

♊️ Близнецы (21 мая — 21 июня)

В этом году сделайте упор на soft skills. Навыки переговоров, управления и тайм-менеджмента ускорят ваше продвижение вперёд. Сентябрь станет самым прибыльным месяцем в году.

Первая половина года подкинет отличную карьерную возможность, не упустите её.

♋️ Рак (22 июня — 22 июля)

Лучшее время для решительных шагов — начало весны. Много возможностей принесёт нетворкинг — поддерживайте тёплые отношения с коллегами, участвуйте в конференциях, митапах и корпоративных мероприятиях. Если ещё не смотрели в сторону Kotlin, самое время это сделать.

♌️ Лев (23 июля — 23 августа)

Год будет спокойным и приятным. В прошлом году вы много работали, в 2022 выделяйте больше времени на отдых. Качество жизни и работы только улучшится. Отличное время для серьёзного обучения — начните какую-нибудь большую книгу или впишитесь в долгие курсы.

Ложитесь спать пораньше, на выходных не заглядывайте в рабочие чаты.

♍️ Дева (24 августа — 22 сентября)

В этом году вы будете на переднем фронте. Вас ждут горячие фиксы и спасение команды перед дедлайном. Будет сложно, но Юпитер вам поможет. Помните об отдыхе и набирайтесь сил в спокойное время.

Зимой возможны серьёзные ошибки в коде или конфигурации, уделите больше времени самопроверке и написанию тестов.

♎️ Весы (23 сентября — 23 октября)

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

Никогда ничего не бойтесь, живите здесь и сейчас

♏️ Скорпион (24 октября — 22 ноября)

В этом году Скорпионам достанутся важные и сложные задачи. Карьерный рост будет спокойным и уверенным — десятки маленьких шагов в течение года выведут вас на новый уровень.

Уделяйте больше времени спорту и друзьям, прокачивайте английский.

Если вы сеньор — углубите навыки System design.

♐️ Стрелец (23 ноября — 21 декабря)

Наступает период, когда пора применить все накопленные знания. А возможности для этого обязательно будут. Юпитер будет мешать делать важные задачи в срок, поэтому закладывайте на выполнение в 2 раза больше времени.

При первой же возможности езжайте в заграничные путешествия.

♑️ Козерог (22 декабря — 19 января)

Год будет положительным и стабильным. Если у вас есть какая-то тактика, придерживайтесь её. Если нет — составьте план развития на год. Подтяните тайм-менеджмент, иначе времени на хобби и внерабочие активности совсем не останется.

♒️ Водолей (20 января — 18 февраля)

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

Уделите больше внимания облачным технологиям.

♓️ Рыбы (19 февраля — 20 марта)

В этом году удача не на вашей стороне, придётся много работать. Хотите успеха — начните сейчас, чтобы уже весной видеть первые результаты. Больше общайтесь с коллегами на неформальные темы, они отличные ребята В марте высокий риск простудиться, одевайтесь теплее.

PS Я включила реакции, и спектр эмоций теперь шире. Но кнопку внизу пока оставила:)

Привет!

Каждый автор пишет о том, что ему интересно, и что больше откликается у аудитории. Я в основном пишу про java core, но хочется писать и на другие темы.

Поэтому хочу узнать про вас чуть больше. Ответьте, пожалуйста, на 2 вопроса выше ⬆️

А если уделите ещё 5 минут и ответите на эту анкету, то сильно мне поможете и напрямую повлияете на будущий контент.

Первым делом хочу поблагодарить всех, кто ответил на анкету и особенно на последний вопрос. Было много приятных пожеланий и интересных идей! Спасибо🥰

Ну а теперь к делу ⬇️

Как написать hashcode лучше, чем IDE

Метод hashcode используется, когда класс работает в качестве ключа в hash-based структурах данных. Следить за тем, как используется класс, не всегда удобно, поэтому есть правило — "Переопределяешь equals — переопредели hashcode".

Метод должен соблюдать контракт:

⭐️ Если объект не меняется, хэшкод остаётся постоянным
⭐️ У одинаковых объектов одинаковый хэшкод
⭐️ Если хэшкод одинаковый, то объекты не обязательно равны

Писать equals и hashcode вручную долго, поэтому часто используется автогенерация в IDE или Lombok аннотация @EqualsAndHashCode. Они создают что-то вроде

public int hashcode() {
  return Objects.hash(id, param1, param2);
}

Что не так?

Контракт соблюдается, но суть хэшкода пропадает.

Хэшкод — это быстрая проверка без лишних вычислений. В коде выше результат вычисляется каждый раз на основе множества полей. А по количеству операций Objects.hashcode догоняет equals.

Как считать хэш быстрее:

1️⃣ Использовать одно поле

public int hashcode() {
   return id;
}

2️⃣ Сохранять результат в отдельном поле

Подойдёт если у объекта нет id, и основные поля не меняются. Так сделано в классе String:

private int hash;

public int hashCode() {
  int h = hash;
  if (h==0 && !hashIsZero){
     hash = …;
  }
  return h;
}

Эффект от оптимизации будет заметен, если класс активно участвует в hash-based структурах. В остальных случаях можно оставить автогенерацию.

Intellij IDEA: создать и переместить строку

Как создают строчку обычные люди: долго переводят курсор в конец строки и жмут Enter.

В IDEA достаточно нажать

Shift + Enter

И вы сразу перейдёте на новую строчку

Быстро перемещать строки:

Shift + Alt + (стрелка вверх/вниз)

Если выделить несколько строк, то группа будет двигаться целиком.

Очень простые и приятные фичи🙂