Почему джависты ищут кнопку «implements»
Когда я, после 17 лет в Java Enterprise, открыл свой первый серьезный проект на Go, я долго не мог понять: как система понимает, какой класс реализует мой интерфейс? Я искал ключевое слово implements, заглядывал в конфиги, грешил на магию компилятора.
Оказалось, всё гораздо проще и... провокационнее. Добро пожаловать в мир Duck Typing (утиной типизации).
Бюрократия Java vs Свобода Go
В Java (особенно в Jakarta EE) интерфейс — это закон. Если ты не объявил явно, что твой класс реализует UserRepository, то никакая сила в мире не заставит компилятор в это поверить. Мы привыкли сначала проектировать иерархию, а потом писать код.
В Go всё наоборот. Если твоя структура имеет метод Save(), она уже реализует любой интерфейс, где есть метод Save(). Ей не нужно об этом заявлять.
«Если это выглядит как утка и крякает как утка — значит, это утка». Для Enterprise-разработчика это звучит как анархия, но на деле это высшая форма развязки (decoupling).
Почему это лечит архитектурную «опухоль»
За годы работы Тимлидом я видел, как в Java-проектах интерфейсы плодятся просто «на всякий случай». Это приводит к жесткой связности: пакет с реализацией должен знать о пакете с интерфейсом.
В Go интерфейсы дают три суперсилы:
- Интерфейсы объявляет тот, кто их использует. Мне не нужно просить автора библиотеки «выдели интерфейс, чтобы я мог написать мок». Я сам описываю в своем коде только те методы библиотеки, которые мне нужны.
- Никаких циклических зависимостей. Поскольку реализации не нужно знать об интерфейсе, мы навсегда забываем о боли, когда пакет А не может импортировать пакет Б, и наоборот.
- Крошечные контракты. В Java интерфейсы часто раздуваются до десятков методов. В Go эталон — интерфейс из 1-2 методов (например, io.Reader). Их легко комбинировать и почти невозможно сломать.
Личный вывод: Стал ли мой код хуже без строгости?
Сначала мне казалось, что без явного implements я потеряю контроль. Но на практике всё иначе. Ты перестаешь строить абстрактные замки и начинаешь думать о поведении объектов.
Теперь, возвращаясь к Java-проектам, я смотрю на наши EJB и сервисы другими глазами. Я стал гораздо строже следовать принципу разделения интерфейса (ISP). Go научил меня: если интерфейс нельзя объяснить одним предложением — значит, это плохой интерфейс.
Заключение
Неявные интерфейсы — это не про хаос. Это про доверие к коду и отказ от лишней бюрократии. После 17 лет в Enterprise это глоток свежего воздуха, который заставляет по-новому взглянуть на чистоту архитектуры.
💬 А как вы считаете: неявные интерфейсы — это путь к чистому коду или прямой путь к запутанному квесту «найди все реализации»? Пишите в комментариях!
Разбираем тонкости Go и Java EE ежедневно здесь: [https://t.me/java_go_way]