6

在过去的 8 年里，我一直在 C# 和 Java 之间来回穿梭。

让我印象深刻的一件事是我已经完全停止在 C# 中使用“模板方法”设计模式。实际上，在 C# 中，我已经开始将这种模式视为一种反模式。

http://en.wikipedia.org/wiki/Template_method_pattern

回到 Java，我发现这种模式是活生生的。我仍然认为它看起来很古老，但意识到在 java 中没有其他方法可以做到这一点。Java 看起来也很古老；）

既然这无论如何都会出现，为什么它是反模式？

  • 很多时候，它会因为“错误的原因”耗尽你的继承层次结构。
  • 基类倾向于散布各种不相关的代码。
  • 它迫使您锁定设计，通常是在开发过程的早期阶段。（在很多情况下过早锁定）
  • 在以后的阶段改变这一点变得越来越难。

因此，对于闭包/委托/函数指针，您通常会传递一些函数而不是子类化。

那么回到问题：

如果您的语言有闭包/委托/函数，您是否使用模板方法，何时使用？

4

3 回答 3

4

当我使用 Java 时，是的。但是对于具有“闭包/委托/功能”的语言，在我的情况下，Lua，不，我不再这样做了，相反，我越来越倾向于装饰模式来满足我的大部分需求。

于 2008-11-21T11:24:16.693 回答
3

是的，我一直使用模板方法，在 D 编程语言中。闭包、委托和函数指针本质上与基类非常松散耦合。当您想要这种松散耦合时，这是一件好事。另一方面，有时您正在自定义的行为本质上与基类非常紧密地耦合。这种行为在几乎任何其他情况下都是无用的。在需要这种耦合的情况下，模板方法模式是最简洁、最简单的表达方式。

一个简单的测试是，如果基类和可定制行为之间的通信是单向的，即基类调用可定制行为，那么您应该始终使用策略/闭包/委托/函数指针。如果可定制的行为需要对基类的引用以便它可以调用方法等，那么模板方法模式通常是最简单的方法。

于 2010-01-14T18:06:27.173 回答
2

在重新访问此线程时，我将再添加一个答案：

当您自定义基础对象的策略需要相互了解并且仅在所有可能组合的非常有限的子集中才有意义时，模板方法模式比策略模式更好。例如，假设您的基类有一个具体的函数doIt()和钩子beforeDoIt()，旨在允许策略自行初始化，并afterDoIt()允许策略自行清理。您不想独立设置这些行为，因为它们只有在配对时才有意义。

于 2010-07-20T17:25:05.430 回答