Is Template Method design pattern and Hook the same thing by different names?

Colleagues,

Is Template Method design pattern and Hook the same thing by different names?
Odd thing is, when I look up hook design pattern on Google, 90% of search results go to pages that describe the Template Method design pattern. I'm trying to find the historical explanation for this. Is Hook a non-OO spiritual precursor to Template Method?

What had prompted me to look into the Hook pattern was this Miro Samek's app note about pattern which he calls "Ultimate Hook". This app note is about message handling by hierarchical state machines. Samek didn't invent the term "Ultimate Hook", though. It was mentioned in 1995 by Petzold in his book on Win 95 programming. The context was plain C. WinMain(...) and WndProc(...) without classes.

Any suggestion, insight or reference is really appreciated!

Cheers,
- Nick

Quote:

---

Originally Posted by kender_a

Samek didn't invent the term "Ultimate Hook", though. It was mentioned in 1995 by Petzold in his book on Win 95 programming.

---

It sounds like the terms are synonymous due to having been named in the literature at roughly the same time. (The GoF book was published in 1995.)

Quote:

---

Originally Posted by kender_a

Is Template Method design pattern and Hook the same thing by different names?

---

I wouldn't say so. Both are based on the general idea of a hook (a place in code which serves as an entry point for some external code) but that doesn't automately make them the same.

Hooking is everywhere (at various levels of abstraction): callbacks, delegation, macroes, virtual tables, indirect dispatches, virtual functions, the CRTP idiom, dependency injection, and even first-class functions.

Looking at the intent of the Ultimate Hook pattern I would say Ultimate Event Handler would be a more telling name.

In addition to the above: the Template method pattern is more about defining a concrete sequence of steps for an operation/algorithm, but with the details of each step abstracted away, so that subclasses can provide different implementations within the "frame" established by the base class.