Это где еще?

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

Это не с потолка взятый кейс, это реальный случай

Для чего нужны геттеры полей - понятно. на работу объекта они не влияют. А сеттеры полей зачем? Я думаю чтоб наделить объект методом, поведение которого разнится в зависимости от заданного поля. Так в таком случае разумно будет в параметры этого метода передавать желаемое значение поля, а по завершению работы метода возвращать поле в дефолтное положение (или не возвращать, зависит от ситуации)

Сеттер просто чтобы заинжектить значение в поле

так это плохо

При чем тут завершение работы метода/ дефолтное значение / разница в поведении

Это его базовое назначение , set - вставка

я пытаюсь разобраться просто являются ли сеттеры и геттеры интерфейсом класса с филосовской точки зрения

интерфейсом? Это методы , не более и не менее

чтобы вас не путать)

А если речь о том стоит ли выносить их выше по иерархии то это плохая идея , имхо

блин, я уже сам ничинаю путаться в значениях слова "интерфейс"

😂😂

я его употреблял в двух смыслах просто

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

Это отражение переменной muttable / immutable - методы доступа.  Ниточкой натянуто можно назвать наверно. Но лучше говорить более явно

я думал понятия muttable / immutable применимы только к объекту. А как тогда называть публичные методы более явно?

интерфейс - грубо говоря это поведение, описывающие ряд действий требующих реализации. У одного класса таких интерфейсов может быть много.
Согласно вашему вопросу, всегда ли нужно для класса городить интерфейс - нет. Чаще всего классы описывающие какую-то сущность (пользователь, запрос, животное) не имплементируют интерфейсы (если не требуется какое-то объединение по поведению).
Для сервисных классов (которые что-то делают с этими сущностями) лучше прописывать интерфейсы и завязываться на абстракцих.

ААааа, вот теперь дошло. Спасибо)