As you might be aware, Template is a GoF behavioral pattern. Here I first explain what the Template pattern is and then show an example of the pattern as implemented in the Spring framework:

Template works on the philosophy of Abstract classes, wherein the Abstract class implements some boiler plate functionality and let the subclasses implement the specifics.

For example, when you want to execute a JDBC query against a database, you have to implement the following steps:

1. Obtain a DataSource
2. Use the DataSource to get a Connection object
3. Use the Connection object to create a Statement (or a PreparedStatement)
4. Execute a query to get the ResultSet
5. Iterate over the results and create a list of VOs (as an example of a business logic)
6. Close the ResultSet
7. Close the Statement
8. Close the Connection

Out of the above steps, most of these are boiler plate code while steps #4 and #5 reflects the actual business logic. If you create a Template class (essentially an Abstract class) that models these steps and allow subclasses to customize the steps #4 and #5 then it will help subclasses reuse the boiler plate code.

Spring does this by providing classes like JdbcTemplate, HibernateTemplate, JmsTemplate etc.  Here is how things work in the Spring world:

Example code:
List results = getHibernateTemplate().executeFind(new HibernateCallback() {
                   public Object doInHibernate(Session session) {
                       Query query = session.createQuery("from Event");
                       query.setMaxResults(2);
                       return query.list();
                   }
});

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming and presented their results at the OOPSLA conference that year. Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994.

Classification:

Design Patterns originally grouped design patterns into the categories Creational Patterns, Structural Patterns, and Behavioral Patterns, and described them using the concepts of delegation, aggregation, and consultation.

Creational patterns

These patterns have to do with class instantiation. They can be further divided into class-creation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation to get the job done.

• Abstract Factory groups object factories that have a common theme.
• Builder constructs complex objects by separating construction and representation.
• Factory Method creates objects without specifying the exact class to create.
• Prototype creates objects by cloning an existing object.
• Singleton restricts object creation for a class to only one instance.

Structural patterns

These concern class and object composition. They use inheritance to compose interfaces and define ways to compose objects to obtain new functionality.

• Adapter allows classes with incompatible interfaces to work together by wrapping its own interface around that of an already existing class.
• Bridge decouples an abstraction from its implementation so that the two can vary independently.
• Composite composes one-or-more similar objects so that they can be manipulated as one object.
• Decorator dynamically adds/overrides behaviour in an existing method of an object.
• Facade provides a simplified interface to a large body of code.
• Flyweight reduces the cost of creating and manipulating a large number of similar objects.
• Proxy provides a placeholder for another object to control access, reduce cost, and reduce complexity.

Behavioral patterns

These design patterns are about classes objects communication. They are specifically concerned with communication between objects.

• Chain of responsibility delegates commands to a chain of processing objects.
• Command creates objects which encapsulate actions and parameters.
• Interpreter implements a specialized language.
• Iterator accesses the elements of an object sequentially without exposing its underlying representation.
• Mediator allows loose coupling between classes by being the only class that has detailed knowledge of their methods.
• Memento provides the ability to restore an object to its previous state (undo).
• Observer is a publish/subscribe pattern which allows a number of observer objects to see an event.
• State allows an object to alter its behavior when its internal state changes.
• Strategy allows one of a family of algorithms to be selected on-the-fly at runtime.
• Template method defines the skeleton of an algorithm as an abstract class, allowing its subclasses to provide concrete behavior.
• Visitor separates an algorithm from an object structure by moving the hierarchy of methods into one object.

Concurrency patterns

Active Object: The Active Object design pattern decouples method execution from method invocation that reside in their own thread of control. The goal is to introduce concurrency, by using asynchronous method invocation and a scheduler for handling requests.

Balking: The Balking pattern is a software design pattern that only executes an action on an object when the object is in a particular state.

Double checked locking : Double-checked locking is a software design pattern also known as “double-checked locking optimization”. The pattern is designed to reduce the overhead of acquiring a lock by first testing the locking criterion (the ‘lock hint’) in an unsafe manner; only if that succeeds does the actual lock proceed.

The pattern, when implemented in some language/hardware combinations, can be unsafe. It can therefore sometimes be considered to be an anti-pattern.

Guarded In concurrent programming, guarded suspension is a software design pattern for managing operations that require both a lock to be acquired and a precondition to be satisfied before the operation can be executed.

Monitor object A monitor is an approach to synchronize two or more computer tasks that use a shared resource, usually a hardware device or a set of variables.

Read write lock A read/write lock pattern or simply RWL is a software design pattern that allows concurrent read access to an object but requires exclusive access for write operations.

Scheduler The scheduler pattern is a software design pattern. It is a concurrency pattern used to explicitly control when threads may execute single-threaded code.

Thread pool In the thread pool pattern in programming, a number of threads are created to perform a number of tasks, which are usually organized in a queue. Typically, there are many more tasks than threads.

Thread-specific storage Thread-local storage (TLS) is a computer programming method that uses static or global memory local to a thread.

Reactor The reactor design pattern is a concurrent programming pattern for handling service requests delivered concurrently to a service handler by one or more inputs. The service handler then demultiplexes the incoming requests and dispatches them synchronously to the associated request handlers.

This is probably the cutest experimental setting I read about the last few months (I do know that I have a particular understanding of what cute is).
Robots, disguised as cockroaches by simple pheromone coating, to make them look like cockroaches, that is at the chemotactility space. Then introduced in a group, to influence dynamically the collective decision-making process. And that works nicely.

More interesting the fact that the programming of robots wasn’t rigid, so they were influenced by natural individual and acted socially in opposition with their individual preferences.

Autonomous artifacts cooperating with living individuals to solve problems. Far away yet from Asimov’s robots, but on the right path.
Now, who wouldn’t like to play with such a setting?

Social Integration of Robots into Groups of Cockroaches to Control Self-Organized Choices
J. Halloy, G. Sempo, G. Caprari, C. Rivault, M. Asadpour, F. Tâche, I. Saïd, V. Durier, S. Canonge, J. M. Amé, C. Detrain, N. Correll, A. Martinoli, F. Mondada, R. Siegwart, J. L. Deneubourg
Science 16 November 2007: Vol. 318. no. 5853, pp. 1155 – 1158 DOI: 10.1126/science.1144259

Collective behavior based on self-organization has been shown in group-living animals from insects to vertebrates. These findings have stimulated engineers to investigate approaches for the coordination of autonomous multirobot systems based on self-organization. In this experimental study, we show collective decision-making by mixed groups of cockroaches and socially integrated autonomous robots, leading to shared shelter selection. Individuals, natural or artificial, are perceived as equivalent, and the collective decision emerges from nonlinear feedbacks based on local interactions. Even when in the minority, robots can modulate the collective decision-making process and produce a global pattern not observed in their absence. These results demonstrate the possibility of using intelligent autonomous devices to study and control self-organized behavioral patterns in group-living animals.