继承和 REST API 控制器 - 处理子类

我正在开发以下优惠券和交易平台的类层次结构：

Promotion - abstract
 - Coupon
 - Sale
 - Deal

(Coupon, Sale and Deal继承自促销。促销有一个名为的字符串属性type以及一个将子类的类型属性初始化为字符串值的抽象方法。例如type在优惠券中获取价值"Coupon" etc...)

对于每个子类，我有一个DAO and Service像这样的课程CouponDAO, CouponService, etc.

在前端用户可以创建Coupon or Sale or a Deal通过角2接口，所以我决定有以下控制器：

PromotionController - abstract
 - CouponController
 - SaleController
 - DealController

(优惠券控制器, 销售主管, 交易控制器继承自促销控制器 )

The PromotionController将包含所有子类共有的所有常见 CRUD 函数，并且在特定控制器中，我将处理针对这些类的特定操作。

A）现在面临的问题是如何实例化来自客户端的正确对象。例如，当用户提交Coupon or a Sale or a Deal我如何实例化正确的对象。例如在促销控制器我有一个这样的功能：：

@RequestMapping(value=CREATE_PROMO, method=RequestMethod.POST)
    public ResponseEntity<?> create(@RequestBody Promotion promotion){
        promotionService.save(promotion);
        return new ResponseEntity<>("", HttpStatus.OK); 
    }

晋升抽象的是函数的参数。我应该使用工厂模式和**type**属性来创建正确的对象？ 例如，如果类型=“优惠券”然后我创建优惠券对象，如果是的话"Sale"然后我创建 Sale 对象

B）由于控制器使用服务对象，这意味着我必须在促销控制器。因为实例化正确的对象后，我需要调用其相应的服务来完成这项工作。在上面的方法中，我有 PromotionService，我认为应该将其替换为子类的正确服务

C) 我正在寻找如何处理现实世界中处理子类的 REST API，就像我上面描述的情况一样

D) 我正在考虑通过将所有 CRUD 操作复制到其特定控制器来让自己变得容易，但似乎这将是重复的代码。

我认为有更好的方法可以做到。

我也尝试过是否可以找到一个处理这种情况的开源项目，但似乎我找到的所有项目都使用一个类而不是继承。他们的 REST/API 不处理继承情况

在我看来，让你的端点保持简单。从 REST API 的角度来看，创建单独的或仅一个控制器，并在控制器层之后使用以下模式。据我所知，最好让 REST 端点远离继承/重用，并在接收和验证请求后应用它。

要从控制器实例化服务/帮助程序层，请使用工厂方法模式：

https://en.wikipedia.org/wiki/Factory_method_pattern https://en.wikipedia.org/wiki/Factory_method_pattern

创建一个 PromotionServiceFactory，它根据促销类型返回 PromotionService 实现。

在控制器中，使用工厂调用相应的升级服务方法。工厂仍然接受 Promotion 类型的参数。

@RequestMapping(value=CREATE_COUPON, method=RequestMethod.POST)
    public ResponseEntity<?> create(@RequestBody Promotion promotion){
//helper if adding one more helper layer. The factory invocation is then //transferred to the helper layer
  PromotionService couponService = promotionServiceFactory.get(PROMOTYPES.COUPON);
couponService.save(promotion);
        return new ResponseEntity<>("", HttpStatus.OK); 
    }

从您的问题来看，不同的促销类型似乎有常见的 CRUD/其他方法。如果每次促销的某些步骤/子任务都是相同的，而其他步骤/子任务则不同，那么这是服务层中模板模式的一个很好的候选者。否则，您可以通过创建抽象升级服务来存储常见的 CRUD 方法。

https://en.wikipedia.org/wiki/Template_method_pattern https://en.wikipedia.org/wiki/Template_method_pattern

使用主要方法和常见 CRUD 方法的实现创建抽象升级服务。使用各自不同的方法创建其他促销服务类型的单独实现。