【问题标题】:is the strategy pattern a good choice to fetch the same information from different sources?策略模式是从不同来源获取相同信息的好选择吗?
【发布时间】:2014-02-14 17:55:13
【问题描述】:

我正在编写一个“主”API 调用,它从不同的供应商那里提取相同的信息。

例如,假设有 2 个供应商,我可以访问他们各自的 REST API 以从用户 Jane 那里提取朋友列表:

供应商 1 给了我 一些 来自 Jane 的朋友。

供应商 2 还给了我 一些 来自 Jane 的朋友,但是供应商 2 给我的朋友列表可能(或可能不)与供应商 1 给我的朋友列表不同。

我需要编写一个脚本,从两家供应商那里提取列表,合并它们并从中删除重复项。

我正在考虑使用策略模式来实现这一点,这样我就可以在运行时交换 API 调用实现,但我想知道这是否适合这种模式。

如果不是,那么哪种设计模式可以让我拥有可变数量的 API 调用实现,并让我在需要加班时添加更多?

我打算使用的语言是 PHP,如果这会影响您的回答。

【问题讨论】:

  • 去做吧,重要的是有一个解决方案,最好是 SOLID 代码。如果您不确定它已经是一个好的解决方案,请不要考虑应该使用哪些模式。模式的名称,或者即使您正在使用它也无关紧要。
  • 别听@MikeSW :) 在现实世界中,您通常不会看到以其模式命名的东西,但好的代码通常确实符合标准设计模式,因此绝对值得考虑这一点……尽管在您完成一段时间后,它会成为第二天性,不会成为您明确停下来反思的事情。

标签: design-patterns


【解决方案1】:

在我看来,您在这里要避免的关键事情是将您的代码与进行 API 调用所需的逻辑相结合和重复数据删除。您应该查看的设计模式是存储库模式。不知道情况的复杂性 我会这样说:

每个使用 API 的对象都应该实现相同的“FriendRepository”接口,以便您获取朋友列表。

然后您的 FriendCompiler 类将包含一个 FriendRepository 接口列表。在您的代码中,您将遍历 FriendRepositories 列表以获取朋友并编译最终列表。 FriendCompiler 类不知道任何 API 的实现细节,List 允许您在运行时从 FriendCompiler 类中添加、更改或删除 FriendRepositories。

【讨论】:

  • Repository 本质上只是一个专门的 Strategy 版本
【解决方案2】:

Strategy = pattern '从而可以在运行时选择算法的行为'(维基百科)。因此,它表明它是适合您的问题的模式。

【讨论】:

    猜你喜欢
    • 2016-10-05
    • 2014-10-29
    • 1970-01-01
    • 2023-02-21
    • 2011-10-02
    • 2014-05-26
    • 2021-07-03
    • 2010-12-06
    • 1970-01-01
    相关资源
    最近更新 更多