为什么JdbcTemplate是模板方法设计模式的一个示例

Question

当我读到关于设计模式，特别是关于模板方法的文章时，我的注意力被这的问题所吸引。

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

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

“在操作中定义算法的框架，将一些步骤推迟到子类。Template方法允许子类在不改变算法结构的情况下重新定义算法的某些步骤。“

有两个参与者：

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

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

• 我看不到在超级/抽象类中定义任何“全局/通用”算法，即使我将它与类似于'JmsTemplate‘的类似文件中的代码进行比较。
• 在具体类中实现的所有函数都不是在超类中定义的。所有定义的方法都是通过使用接口来添加的，在这种情况下，接口'JdbcOperations'，没有一个真正覆盖父方法中的方法。

我知道这是非常方便的消除 样板码。但是为什么这是一个模板方法，而不仅仅是一个巧妙的编码技巧。在我看来，它似乎没有模板方法所具有的任何特性。

Answer 1

GoF中的两种设计模式代表了类似的想法-

“在操作中定义算法的框架(泛型API)，并将一些专门化的步骤委托给客户端。

1. 模板设计模式：专门化是通过子类完成的。(这不是JdbcTemplate中的方法。
2. 策略：专门化是通过回调(委托)完成的。(这是JdbcTemplate中的方法。我们使用像ResultSetExtractor这样的回调，它提供了专门化逻辑)

JdbcTemplate is more a strategy than template.

Answer 2

我同意- JdbcTemplate不是模板方法设计模式的一个例子。使用的设计模式是https://en.wikipedia.org/wiki/Callback_%28computer_programming%29。

请注意，这两种模式的目标和效果非常相似，主要的区别是模板方法使用继承，而回调使用组合(某种程度)--请参阅继承，以了解为什么可能更喜欢这种方式。

Answer 3

根据JdbcTemplate文档

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

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