我有一个场景,其中有一个服务聚合器,以skyscanner或kayak或Google航班为例。如果您看到了,他们都会询问基本的详细信息,例如什么是来源,目的地,日期和乘客人数,一旦您从特定的服务提供商处选择了航班,比如说Expedia,您将被重定向到Expedia,其中包含由服务聚合器发送过来的
现在,从源系统发送的参数名称可能有所不同,在目的地,我们必须将其转换为相同的POJO。
我想到的一个选项是Factory模式,基于通道,我将返回一个对象,该对象会将源参数转换为公共POJO。
我认为相似的其他设计模式是“策略设计模式”,用于基于上下文创建ExtractionStrategy
还有其他适合的设计模式来解决此问题吗?
答案 0 :(得分:2)
恕我直言,保持实施尽可能简单,我建议您采用简单的工厂模式。 定义工厂服务以仅执行2个操作:
定义一个具有POJO公用字段的父类(例如 BasePOJO ),然后扩展所有其他类型的源聚合POJO(假设所有字段都具有不同的字段名称等)。由于您的每个来源agg。类将具有自己的逻辑来创建特定于该类型的源聚合器的POJO。
链接每个源类隐含。保持以下类型的枚举:(sourceType,sourceAggClass)
例如:
枚举sourceAgg { (EXPEDIA,ExpediaModelImpl), (VIA,ViaModelImpl); }
您所要做的就是从枚举中获取基于源聚合器键(例如 EXPEDIA )的实现,因为您在上下文中具有bean名称,因此可以轻松调用每种类型的transformModel 函数。 transformModel 从每个源agg返回的对象。类的类型为BasePOJO,它很容易作为形式参数进行处理。
将来,如果您想添加新的源聚合器,您所要做的就是编写该类的转换模型并添加枚举映射,就是这样!
PS:这是我的第二个回答,非常欢迎提出建议。