Java

See the official "Core J2EE Patterns" and the Core J2EE Patterns learning trail

A couple of J2EE design patterns are briefly described on this blueprints guidelines page:

• Intercepting filter--This pattern applies to request pre- and post-processing. It applies additional services needed to process a request. For example, an intercepting filter such as a servlet filter may handle all incoming requests to the Web site and provide a central mechanism for authorization.
•  View helper--A view helper encapsulates the presentation and data access logic portions of a view, thus refining the view and keeping it simpler. Presentation logic concerns formatting data for display on a page, while data access logic involves retrieving data. View helpers are often JSP tags for rendering or representing data and JavaBeans for retrieving data.
•  Composite view--This pattern makes view presentation more manageable by creating a template to handle common page elements for a view. Often, Web pages contain a combination of dynamic content and static elements, such as a header, footer, logo, background, and so forth. The dynamic portion is particular to a page, but the static elements are the same on every page. The composite view template captures the common features.
•  Front controller--This pattern provides a centralized controller for managing requests. A front controller receives all incoming client requests, forwards each request to an appropriate request handler, and presents an appropriate response to the client.
•  Value object--This pattern facilitates data exchange between tiers (usually the Web and EJB tiers) by reducing the cost of distributed communication. In one remote call, a single value object can be used to retrieve a set of related data, which then is available locally to the client. See Chapter 5 for more information on value objects.
•  Session facade--This pattern coordinates operations between cooperating business objects, unifying application functions into a single, simplified interface for presentation to the calling code. It encapsulates and hides the complexity of classes that must cooperate in specific, possibly complex ways, and isolates its callers from business object implementation changes. A session facade, usually implemented as a session bean, hides the interactions of underlying enterprise beans.
•  Business delegate--This pattern intervenes between a remote business object and its client, adapting the business object's interface to a friendlier interface for the client. It decouples the Web tier presentation logic from the EJB tier by providing a facade or proxy to the EJB tier services. The delegate takes care of lower-level details, such as looking up remote objects and handling remote exceptions, and may perform performance optimizations, such as caching data retrieved from remote objects to reduce the number of remote calls.
•  Data access object--This pattern abstracts data access logic to specific resources. It separates the interfaces to a systems resource from the underlying strategy used to access that resource. By encapsulating data access calls, data access objects facilitate adapting data access to different schemas or database types. See Chapters 5 and 6 for more information on data access objects.

• Core J2EE Patterns. D. Alur, J. Crupi, D. Malks. Copyright 2001, Prentice Hall PTR.
•  Design Patterns. E. Gamma, R. Helm, R. Johnson, J. Vlissides. Copyright 1995, Addison-Wesley.
•  Refactoring: Improving the Design of Existing Code. M. Fowler, et al. Copyright 1999, Addison-Wesley.
•  Pattern-Oriented Software Architecture, Volume 1: A System of Patterns. F. Buschmann, et al. Copyright 1996, John Wiley & Sons.
•  Pattern-Oriented Software Architecture, Volume 2: Patterns for Concurrent and Networked Objects. D. Schmidt, et al. Copyright 2000, John Wiley & Sons.