为什么喜欢模板方法而非依赖注入？

Posted 2021-05-05

我一直在阅读Gamma等人的Design Patterns。与依赖注入相比，我有一个关于模板方法的问题。

使用模板方法，您可以使用策略“模板化”类，这些策略提供所需操作或计算的替代方法。因此，不是从多个备选方案中选择一个策略并将该策略编码到类中，而是允许类的用户指定他们想要使用的替代方案。

这听起来对我来说非常合理。但我打了一个概念性的砖墙。

如果使用策略对象实例化类，则策略对象需要实现抽象接口。然后，程序员可以编写所有编译到类中的不同策略，而不会出现错误，因为策略实现了接口。使用策略的类将编码到策略接口而不是实现。

如果你要为这些策略对象定义一个抽象的IPolicy，为什么不使用依赖注入并在构造中传入IPolicy？

任何人都可以解释为什么你更喜欢模板方法依赖注入？

答案

关于“模板方法”（而不是设计模式），以下示例可能有助于确定要做什么的优点和缺点。该示例是创建用于帮助调试/开发的库的详细模式。

随着模板

struct console_print
{
  static void print(const string& msg) {std::cout<<msg;}
};

struct dont_print
{
  static void print(const string& msg) {}
};

template<printer>
void some_function()
{
  printer::print("some_function called
");
}

然后库用户可以写：

some_function<console_print>(); //print the verbose message;
some_function<dont_print>();    //don't print any messages.

这段代码的好处是，如果用户不想打印代码，那么对dont_print::print(msg)的调用将完全从代码中消失（空的静态类很容易被优化掉）。然后可以将这种调试消息输入甚至性能关键区域。

模板的缺点是您需要在编译之前确定策略。您还需要更改任何模板的函数/类签名。

没有模板

当然可以通过以下方式完成上述操作：

struct printer 
{
  virtual void print(const std::string& msg) = 0;
}

struct console_print : public printer
{
  void print(const std::string& msg) {std::cout<<msg;}
}
struct debug_print : public printer
{
  void print(const std::string& msg) {}
}

这样做的好处是，您可以将打印机类型传递给类和函数，并在运行时更改它们（对某些应用程序可能非常有用）。但是，成本是始终对虚函数进行调用，因此空dont_print确实具有较小的成本。对于性能关键区域，这可能是也可能不是可接受的。

另一答案

首先，正如菲涅尔所提到的，模板方法模式不是现代意义上的模板。再次阅读它，它使用运行时多态来实现STL算法使用编译时多态性（函数模板）的相同目标。

其次，从某种意义上说，各种多态性都是依赖注入。也就是说，调用者将算法引入其作用的具体类型。所以问题一般不是你是否能够或应该使用依赖注入而不是其他模式：相反，模式显示了构造代码以使用依赖注入的有用方法。

如果您的“注入依赖项”是模板类型参数，则算法使用duck typing并且您不必实现抽象接口：只需编写具有预期签名的方法。

另一答案

在你的情况下“模板方法”（不要与Template Method Pattern混淆），或者让我们称之为“静态依赖注入”，将避免使用虚函数。您主要通过为编译器提供更多和明确的知识来获得性能，从而为他提供更好的优化机会。这些类变得更加静态，类型安全性也会增加。

类大小可能会缩小（不存储或减少存储指针的需要）。

俗话说：

不要为你不使用的东西买单。

这里适用。如果您不需要虚拟接口，模板可帮助您避免使用虚拟接口，而不会牺牲所有灵活性。