适配器和访问者模式是否适合我的用例？答案

【问题标题】：Are Adapter and Visitor patterns appropriate for my use cases?适配器和访问者模式是否适合我的用例？
【发布时间】：2016-06-23 16:36:37
【问题描述】：

我的用例是我向返回不同外部数据类型的各种 API 发出请求。然后我必须使用从其他 API 检索到的其他元数据来装饰数据。然后我根据客户的需求返回响应。

首先我对数据提出请求，然后根据这些结果检索每条数据的适当元数据。

到目前为止我的方法：

我关心#3（编辑：我关心的是#4，而不是#3）。在适应的内部类型上使用访问者模式是否合适，还是有更简单的方法？创建每个以不同方式依次改变对象的访问者操作是否是一种好习惯？（即在数据对象列表中设置字段）

【问题讨论】：

你发布最少的代码？
对我来说，您的第 3 步和第 4 步是联系在一起的：您似乎对第 3 步感到担忧，但对第 4 步提出了问题（使用您的访问者来改变对象）。您能否提供有关这些步骤的更多详细信息？输入类型的数量与变异任务的数量应该是判断访问者模式是否最适合的决定性因素。
糟糕，我的意思是我担心第 4 步，抱歉。假设步骤 1 获取 Zoo 对象列表，其中包含一些元数据，例如动物 ID 列表，但不是全部。此外，获取 Zoos 有不同的 API，但它们的类型不同，因此我们将它们调整为一致的内部接口。但是，我们缺少动物的详细信息，因为我们只有动物 ID。我们调用更多的 API 并传递这些动物 ID 来填充年龄、位置等空白字段。这些空白字段在我们检索元数据后会发生变化。请让我知道这是否足够详细，谢谢
@Ravindrababu 我认为这更像是一个设计问题而不是编码问题，对吧？如果您不同意，请告诉我
变异适应的内部对象：我认为它应该是构建器模式。 stackoverflow.com/questions/34726422/…

【解决方案1】：

根据我们在聊天中的讨论：

用访问者模式改变适应的内部对象

实际上你的要求可以用Builder模式而不是访问者模式来满足，因为你必须逐步构建对象。

Visitor 是一种行为模式，用于不同的目的：

必须对结构中分组的不同类型的对象执行类似的操作