Определение типов подклассов с атрибутом

Question

У меня есть следующая иерархия классов

Promotion   -  abstract
  - Coupon
  - Sales
  - Deals

(Купоны, Продажи и Предложения - все подклассы Поощрения).

и хотел бы определить тип объекта при обмене даннымимежду API REST (JSON) и клиентом (Angular).Пользователи могут отправить купон или сделку или продажу .Например, когда клиент отправляет купон, я хочу знать, что это купон, чтобы я мог вызвать правильный метод.

Чтобы решить эту проблему, я объявил переменную и абстрактный метод.в акции.

protected String promotionType = getPromotionType();
protected abstract String getPromotionType(); 

В подклассах, например, в Купон У меня есть что-то вроде этого

protected String getPromotionType() {
        return "coupon"
       // OR  return this.getClass().getSimpleName().toLowerCase();
    }

Это автоматически инициализирует promoType переменная, так что в контроллерах я могу проверить, является ли объект купон или продажи или сделки .Помните, что JSON отправляет данные в строковых форматах, поэтому я должен определить способ прихода объекта.

В этом случае у меня будет один контроллер для обработки всех моих операций CRUD.В моем методе контроллера я сделаю что-то вроде: *

@PostMapping public void create(@RequestBody Promotion){

     // And inside here I will check the type of **promotionType**

}

Здесь я использую Promotion в качестве аргумента вместо любого из подклассов в методе create () .

Мой вопрос: это лучший способ решить эту проблему?

Или мне нужно создать отдельный контроллер для каждого из подклассов?Я ищу лучший способ сделать это в реальном мире.

Я использую Hibernate для своих отображений.

Answer 1

Мой вопрос: это лучший способ решить эту проблему?

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

Или мне нужно создать отдельный контроллер для каждого подкласса?

Нет, не обязательно.Если код и, вероятно, останется простым - иногда вы можете предвидеть это - не имеет смысла раздувать код.Наличие трех Controllers вместо одного PromotionController очень вероятно увеличит избыточный код.В противном случае, если подклассы довольно неоднородны, три контроллера могут быть более целесообразными.

Другая мысль: у вас может быть (человеческий) клиент, который управляет только Deals, и у этого клиента есть особые требования, приводящие к кученастраиваемых интерфейсов отдыха только для Deal, вы, вероятно, хотели бы иметь отдельный Controller.

Я ищу лучший способ сделать это в реальном мире.

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

Лучший способ - это обсудить это в команде, создать здравый смысл и, если не уверены, позволить ведущему архитектору решить, какой путь выбрать.Имо, ваш подход кажется вполне нормальным.Это мои 2 цента.