我有一个场景，其中有一个服务聚合器，例如skyscanner、皮划艇或谷歌航班。如果你看到了，他们都会询问基本的详细信息，比如来源、目的地、日期和乘客人数，一旦你从特定的服务提供商那里选择了航班，比如expedia，你就会被重定向到expedia上，并通过服务聚合器发送预填的详细信息
现在，从源系统发送的参数的名称可能会有所不同，在目的地，我们必须将其转换为相同的POJO。
我想到的一个选项是Factory模式，基于通道，我将返回一个对象，该对象将把源参数转换为通用POJO。
我觉得类似的另一种设计模式是策略设计模式，即基于上下文创建ExtractionStrategy
有没有其他合适的设计模式来解决这个问题？
IMHO尽可能简化实现，我建议您使用简单的工厂模式。定义一个工厂服务，只执行两个操作：
- 获取所有参数的指定Map，如source、dest。日期等
- 现在有一个简单的方法transformModel(Map，SourceAgg Type(
定义一个具有POJO公共字段的父类(比如BasePOJO(，然后扩展所有其他类型的源聚合器POJO(假设所有POJO都有不同的字段名等(。自从你的每一个源agg。类将有自己的逻辑来创建特定于该类型的源聚合器的POJO。
链接每个源类impl。维护一个枚举：(sourceType，sourceAggClass(
例如：
枚举源Agg{(EXPEDIA、ExpediaModelImpl(，(VIA，ViaModelImpl(；}
您所要做的就是从枚举中获得基于源聚合器键(比如EXPEDIA(的实现，因为您在上下文中有bean名称，所以可以很容易地为每种类型调用transformModel函数。transformModel从每个源agg返回的对象。类将是BasePOJO类型，因此很容易作为形式化参数处理。
在未来，如果你想添加新的源聚合器，你所要做的就是编写该类的转换模型并添加枚举映射，就这样！
附言：这是我对SO的第二个回答，欢迎提出建议。