php - 这是策略模式的一个很好的用例吗？

Question

我正在使用一个需要接收多个视频并在特定页面上显示它们的应用程序，目前这些视频只能来自 YouTube，由于不允许其他提供商的实现，因为代码要获取视频数据作为预览图像，直接放在负责显示视频的 View Helper 中。

我想更改此结构以便轻松添加新的提供程序，例如 Vimeo，并且我认为策略模式是理想的，我将在我的 View Helper 中使用方法 setVideoUrl( string $url )，此方法将从 class VideoProviderFactory 调用方法 getProviderStrategy( string $url )，然后此工厂类将返回策略类(如果可用) ，它实现了视频 url 提供者的 interface VideoProvider。

你怎么看？这是对的？我需要改变什么吗？

细节:我最初想在View Helper中直接放一个选择策略的开关，但看了这个问题后:我Strategy Pattern with no 'switch' statements?我发现我错了，然后 class VideoProviderFactory 出现了。

Answer 1

这看起来是一个非常好的设计，具有适当的职责分离。

为了给您更多思考，请考虑工厂将如何决定创建哪种策略。稍后当您想要添加另一个策略时，需要更改什么？首先，您要创建一个新的 VideoProvider，然后您必须更改工厂 switch 语句(如您所描述的)并包括这个新的选择逻辑战略。现在，这在大多数情况下都很好，但是如果您想在不更改工厂的情况下添加新策略怎么办？

一种方法是使用一个类似工厂的接口(interface)，该接口(interface)带有一个方法，该接口(interface)根据 URL 决定是否应该创建一个特定的 VideoProvider；我们称它为 VideoProviderMatcher(伪代码):

interface VideoProviderMatcher {
  bool understands(url)
  VideoProvider create()
}

现在，此接口(interface)知道它是否理解 URL 以及如何创建与其相关的 VideoProvider。当您需要创建新策略时，您可以同时实现 VideoProvider 和相关的 VideoProviderMatcher。至于工厂，它更改为封装 VideoProviderMatcher 列表，并使用责任链(伪代码)委托(delegate)给第一个理解给定 URL 的人:

class VideoProviderFactory {
  List[VideoProviderMatcher] matchers
  void registerMatcher(VideoProviderMatcher matcher) {
    matchers.add(matcher)
  }
  VideoProvider getVideoProviderFor(url) {
    foreach (matcher in matchers) {
      if (matcher.understands(url)) return matcher.create()
    }
  }
}

现在唯一需要更改的代码是首先创建工厂的代码。理想情况下，它有一个用于填充工厂的 VideoProviderMatcher 列表，您只需将另一个项目添加到列表中即可。

现在，这值得吗？我会说这取决于匹配逻辑的复杂程度，与视频提供者一起封装URL匹配的意愿，添加新策略时保持工厂稳定的愿望以及添加新策略的速度解决方案。