Presentation Tier

• Intercepting Filter
  If the intent is to do some pre or post processing with the request or response of an application, use this pattern.
• Front Controller
  If the intent is to have a centralized request handling mechanism that dispatches to appropriate handler, use this pattern.

Business Tier

• Business Delegate
  If the intent is have single point of entry for the client to access business services, use this pattern. Especially, we we want to separate the presentation tier and the business tier.
• Composite Entity
  If the intent is to manage a graph of persistent objects using a primary composite entity, use this pattern. Example, if the composite entity is updated, the internally independent beans will get updated.
• Service Locator
  If the intent is to locate services using JNDI lookup, use this pattern. However, considering the cost of the looking up JNDI it should employ the use of caching technique.
• Session Facade
  If the intent is to encapsulate business-tier components and expose a coarse-grained service to remote clients, use this pattern. Instead of the client accessing the business components directly it is accessing the session facade.
• Transfer Object (a.k.a Value Object)
  If the intent is to pass data with multiple attributes in one shot from client to server, use this pattern. Normally, this pattern is implemented using POJO having getter/setter methods and must be serializable.
• Value List Handler
  If the intent is to manage the small or large results of a search operation that can be paged and can be traverse iteratively, use this pattern.

Integration Tier

• Data Access Object (a.k.a. Separation of Logic)
  If the intent is the separate the data persistence logic in a separate layer, use this pattern.
• Service Activator
  If the intent is to invoke a service asynchronously, use this pattern. A good example of this is JMS (Java Message Service) listener where it waits for a messaging request and understand it to delegate it to an appropriate service. While the response can be done by either the service activator or the service.

Behavioral design patterns are design patterns that are focusing on the interactions between objects and mostly trying to be loosely coupled.

• Chain of Responsibility
  If the intent is to decouple a request from a handler in a chain of handlers until it is finally recognized, use this pattern.
• Command
  If the intent is to encapsulate a request as an object, use this pattern.
• Interpreter
  If the intent is to interpret a grammar of a language, use this pattern.
• Iterator
  If the intent is to navigate a container without exposing the structure of an object, use this pattern.
• Mediator
  If the intent is to make objects interacts without them really referring to each other, this is the pattern to use.
• Memento
  If the intent is to externalize the object state that normally provides rollback functionality, use this pattern.
• Null Object
  If the intent is to avoid an explicit null check, use this pattern to encapsulate the default behavior or do nothing behavior.
• Observer
  If the intent is to have a subject that can be observed by one or more observers, use this pattern.
• State
  If the intent is to have the state as part of an object rather than storing it in a variable, use this pattern.
• Strategy
  If the intent is to select an algorithm at runtime, use this pattern.
• Template method
  If the intent is to define an algorithm that allows the sub-classes to redefine parts without changing it's structure, use this pattern.
• Visitor
  If the intent is to separate the algorithm from an object structure, this is the pattern to use.

Structural Design Patterns

Structural design patterns are design patterns that are mainly focusing on how to use objects (e.g. Performance, memory utilization, interception).

• Adapter
  If an interface of another class needs to be used as another interface, use this pattern.
• Bridge
  If the abstraction need to be decoupled from the implementation and allowing both to be modified without affecting each other, use this pattern.
• Composite
  If the intent is to have some objects of the same type into tree structure, use this pattern.
• Decorator
  If adding a behavior to an object of the same type dynamically at runtime without affecting their own behavior, use this pattern.
• Facade
  If the need of have a simplified interface from a complex and difficult to use API because of the large interdependent classes or the codes is not accessible, use this pattern.
• Filter (a.k.a. Criteria)
  If the intent is to filter a set of objects using different criteria and has the capability to chain them in a decoupled way, use this pattern.
• Flyweight
  If the desire to conserve memory by sharing as much data as possible, use this pattern.
• Proxy
  If there's a need for a class to function as an interface to something else, use this pattern. The proxy can just forward to the a real object or provides some additional logic.

Creational design patterns are design patterns that mainly focusing on the creation of object that's appropriate to a particular scenario.

• Singleton
  Only one an only instance of a particular class is required, use this pattern.
• Builder
  If the creation of objects are complex (i.e. requires a lot of constructors and properties), this is the pattern of choice.
• Prototype
  When the object creation is so expensive and cloning is more lighter, this is the pattern of choice.
• Factory
  If hiding the instantiation logic was desired and only exposes the common interface, use this pattern.
• Abstract Factory
  If multiple factories were created and have a common objectives we can group these to an abstract factory. This is also known as factory of factories.
• Dependency Injection
  If the intent is to have an object supplies the dependencies of another object, this is the pattern to use.