наверное самый простой и тупой способ добавить поле type типа String и дергать из дб по этому полю(через метод сервиса, например getByType)

Да, уже добавил, только Enum, спасибо

Теперь вопрос следующий: нужно создавать объект типа type, где type передается в @PathVar и конвертируется сразу в EmployeeType.  Есть ли способ создавать нужный подтип без использования  switch? Просто с ним придется каждый раз, как мы добавляем новый подтип, переписывать этот "маппинг", добавляя в switch новый тип.

Да, уже добавил, только Enum, спасибо

Теперь вопрос следующий: нужно создавать объект типа type, где type передается в @PathVar и конвертируется сразу в EmployeeType.  Есть ли способ создавать нужный подтип без использования  switch? Просто с ним придется каждый раз, как мы добавляем новый подтип, переписывать этот "маппинг", добавляя в switch новый тип.

Привет

Контекст:
Делаю Rest на Spring Boot.
Структура такова, что есть абстрактный Employee от которого наследуется условные Programmer и Manager.

Прочел, что лучше всего сделать такой endpoint :

test.com/employee?type='Manager'

Который вернёт всех Employee типа Manager.

Как лучше организовать передачу типа? Хочу сделать так чтобы можно было масштабировать систему типов ничего не меняя в контроллере Employee, а лишь добавить класс, который его наследует.

Привет

Контекст:
Делаю Rest на Spring Boot.
Структура такова, что есть абстрактный Employee от которого наследуется условные Programmer и Manager.

Прочел, что лучше всего сделать такой endpoint :

test.com/employee?type='Manager'

Который вернёт всех Employee типа Manager.

Как лучше организовать передачу типа? Хочу сделать так чтобы можно было масштабировать систему типов ничего не меняя в контроллере Employee, а лишь добавить класс, который его наследует.

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

наследовние не нужно, просто заведи Enum

чем твой емплоер от менеджера будет отличатся помимо имени класса?

Расчетом зарплаты, методами

В будущем много чем может(правами доступа и тд)

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


сами классы данных не должны в себе логику содержать, иначе там черт ногу сломит

А расчет значений, которые лежат только в этом классе и относятся только к нему.

Да, вот как раз, то что ты последним написал

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

Выносить их в отдельную логику - только засорять файлами дерево

если у тебя все будет в методах этих сущностей, то классы разростуться до жути

плюс и права доступа и зарплата — все в одном классе это такое

Наверное, если у тебя подклассы обозначают определённые профессии/должности, то можно уйти от наследования к композиции или аггрегации

В employee, у всех же есть имя и фамилия