экономия на байтах

давайте и дальше функции strtr называть, штош

У меня в проекте 63 сервиса с похожими названиями , а теперь представим если б они все еще с i начинались. Сейчас я могу ввести G и выйдет пачан сервисов обвязанный вокруг какого нибудь генератора но тут надо В 2 РАЗА больше писать. Не спорю что аргумент чуток высосан из пальца но имеет место жить)

Читаемость улучшится?

в два раза больше писать эт про нажать лишнюю кнопку на клаве? беда.

Ес )

тогда вообще наверное стоит пеп8 на вооружение взять. там пробелы вокруг равно запрещены.

Пробелы вокруг равно повышают читаемость приведи 1 плюс бесполезного префикса для интерфейсов в устоявшемся кодстайле?

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

Согласен

Второй кейс понятен, а первый про что? Чет не допер

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

А. Моккинг

Ну это уже кейс, где все таки планируется больше одной имплементации.

А почему нельзя просто заэкстендить класс, зачем именно java interface юзать. Чем класс не интерфейс

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

> заэкстендить

так весь связанный геморрой никуда не денется тогда

> чем класс не интерфейс

а ю джокинг

Дело привычки. Просто единообразно делайте.

Какой геморрой? Для тестов заэкстендили, переопределили что нужно.
Чем публичные методы класса - не интерфейс в широком смысле?

ты не можешь не вызвать супер и не прокинуть то, что ему нужно для работы