контракт описывающий то как пользоваться функционалом. Он скрывает реализацию. Для ваших коллег это отправная точка, куда они будут смотреть испоользуя ваш код. В своих собственных проектах - можно и без интерфейсов. На работе же (особенно в энтерпрайзе) всё же стоит уделять внимание контрактам. Вы же не имплементируете API без описания (нормально задокументированной спецификации в openapi?... нет же 🙂 )
Ну вот дергаю я сервис , вижу я его сигнатуру userService.getUserById(Long id) - имеется разница вызываю я интерфейс или реализацию? В случае с контрактами реализация ею и будет. Хибер так появился и норм себе живет (ток не для соседнего чата)
Нет, неправильно. У нас достаточно развитые языки программирования (джава в том числе), которые позволяют описывать поведение и в классе - модификаторы доступа существуют не случайно.
Ну условно если бы не спринг на котором многие сидят…или любой другой фреймворк где нужны сеттеры/геттеры То если вы напишите someObjectInstance.field вместо someObjectInstance.getField() Ничего бы нигде никогда не сломалось, не изменилось бы вообще ничего, только геттеры/сеттеры можно было бы выкинуть и поля не private сделать
Да, я давно говорю, что сеттеры и в чуть меньшей мере геттеры - хуйня из-под коня, и public final наше всё, да. У самого кодовая база без геттеров-сеттеров, никто не умер.
Обсуждают сегодня