4

当我的注意力被 SO 上的这个问题吸引时，我正在阅读有关设计模式的内容，特别是有关模板方法的内容。

在阅读了解释和具体代码之后，我仍然想知道为什么这是“模板方法”设计模式的一个例子。

根据 GoF 的说法，这种模式的意图是：

“在操作中定义算法的骨架，将一些步骤推迟到子类。模板方法让子类在不改变算法结构的情况下重新定义算法的某些步骤。”</p>

并有两个参与者：

AbstractClass :
- 定义具体子类定义的抽象原始操作以实现算法的步骤
- 实现定义算法骨架的模板方法。模板方法调用原始操作以及在 AbstractClass 中定义的操作或其他对象的操作。
ConcreteClass：
实现原始操作以执行算法的子类特定步骤。

为什么“JdbcOperations”中的代码被认为是“模板方法”设计模式？

  • 我没有看到在超级/抽象类中定义了任何“全局/通用”算法，即使我将它与类似文件中的代码（如“JmsTemplate”）进行比较。
  • 在具体类中实现的功能都没有在超类中定义。所有定义的方法都是通过使用接口添加的，在本例中是接口“JdbcOperations”，实际上没有一个方法会覆盖父级中的方法。

我知道它对于消除样板代码非常方便 。但为什么这是一个模板方法，而不仅仅是一个漂亮的编码技巧。对我来说，它看起来不像模板方法所具有的任何特征。

4

3 回答 3

3

GoF 中的两种设计模式代表了相似的理念——

“在操作中定义算法的骨架（通用 API），并将一些专门的步骤委托给客户端。

  1. 模板设计模式：专业化是通过子类化完成的。（这不是 JdbcTemplate 中的方法。

  2. 策略：专业化由回调（委托）完成。（这是 JdbcTemplate 中的方法。我们使用像 ResultSetExtractor 这样的回调，它提供了专业化逻辑）

JdbcTemplate is more a strategy than template.

于 2017-06-18T10:31:32.243 回答
2

我同意 -JdbcTemplate不是模板方法设计模式的一个例子。使用的设计模式是回调。

请注意，两种模式的目标和效果非常相似，主要区别在于模板方法使用继承，而回调使用组合（有点） - 请参阅https://en.wikipedia.org/wiki/Composition_over_inheritance了解为什么会这样首选。

于 2015-10-15T16:20:31.503 回答
1

根据JdbcTemplate文档

它简化了 JDBC 的使用并有助于避免常见错误。它执行核心 JDBC 工作流，让应用程序代码提供 SQL 并提取结果。此类执行 SQL 查询或更新，在 ResultSets 上启动迭代并捕获 JDBC 异常并将它们转换为 org.springframework.dao 包中定义的通用、信息更丰富的异常层次结构。

JdbcTemplate为每个方法的内部工作提供抽象。例如insert()或update()在内部使用所选数据库的具体类的实现。客户端代码不必知道或实现这些方法，因为它们是由数据库供应商实现的。这就是它与Template设计模式紧密匹配的原因。

于 2015-10-15T16:33:01.773 回答