爲什麼JdbcTemplate是模板方法設計模式的一個例子

Question

我正在閱讀關於設計模式的內容，特別是關於模板方法，當時我的注意力被this問題抓住了。

閱讀解釋和具體代碼後，我仍然想知道爲什麼這是'模板方法'設計模式的一個例子。

根據GoF的，這個圖案的意圖是：

「定義的算法的骨架中的操作時，某些步驟推遲到子類。模板方法讓子類重新定義算法的某些步驟，而不需要改變算法的結構「

，有兩個參與者：

抽象類：
- 定義抽象的基本操作是具體子類定義了。實施算法步驟
- 實現定義算法框架的模板方法。模板方法調用基本操作以及在AbstractClass中定義的操作或其他對象的操作。
具體類別：
實現原語操作以執行算法的子類特定步驟。

---

爲什麼在「JdbcOperations」的代碼被認爲是一個「模板方法」設計模式？

• 我沒有看到超級/抽象類中定義的任何'全局/常規'算法，即使我將它與類似'JmsTemplate'類似文件中的代碼進行比較。
• 在超類中也沒有定義在具體類中實現的函數。所有定義的方法都是通過使用接口來添加的，在這種情況下是接口'JdbcOperations'，並且沒有一個實際覆蓋父接口中的接口。

我得到的事實是它是extremely handy for eliminatingboilerplate code。但爲什麼這是一個模板方法，而不僅僅是一個漂亮的編碼技巧。對我來說，它看起來像它沒有共享模板方法所具有的特徵。

Answer 1

我同意 - JdbcTemplate不是模板方法的例子設計模式。使用的設計模式是callback。

注意到，這兩個模式的目標和效果是非常相似，主要區別在於模板方法使用繼承而回調使用成分（在某種程度上） - 見https://en.wikipedia.org/wiki/Composition_over_inheritance爲什麼這可能是首選。

Answer 2

由於每JdbcTemplate文檔

它簡化了JDBC的使用，並有助於避免常見錯誤。它 執行核心JDBC工作流程，留下應用程序代碼以提供SQL 並提取結果。該類執行SQL查詢或更新， 啓動對ResultSets的迭代並捕獲JDBC異常，並將它們轉換爲org.springframework.dao包中定義的通用，更具信息性的異常層次結構 。

JdbcTemplate爲每個方法的內部工作提供了抽象。對於例如insert()或update()內部使用所選數據庫的具體類的實現。 客戶端代碼不必知道或實施這些方法，因爲它們是由數據庫供應商實施的。這就是它與Template設計模式緊密匹配的原因。

Answer 3

兩個在GoF的設計模式表示類似idea-

「定義的算法的骨架中的操作（通用API），和委派一些專門的步驟到客戶端。

1. 模板設計模式：專業化是通過子類化來完成的（這不是JdbcTemplate中的方法

2. 策略：專業化由回調（委託）完成。 （這是在JdbcTemplate的。我們使用回調像ResultSetExtractor類提供專業化邏輯的方法）

JdbcTemplate is more a strategy than template.