Design Patterns in software architecture

• Abstract Factory
  Creates an instance of several families of classes
• Builder
  Separates object construction from its representation
• Factory Method
  Creates an instance of several derived classes
• Object Pool
  Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
• Prototype
  A fully initialized instance to be copied or cloned
• Singleton
  A class of which only a single instance can exist

These design patterns are all about Class and Object composition. Structural class-creation patterns use inheritance to compose interfaces. Structural object-patterns define ways to compose objects to obtain new functionality.

• Adapter
  Match interfaces of different classes
• Bridge
  Separates an object’s interface from its implementation
• Composite
  A tree structure of simple and composite objects
• Decorator
  Add responsibilities to objects dynamically
• Facade
  A single class that represents an entire subsystem
• Flyweight
  A fine-grained instance used for efficient sharing
• Private Class Data
  Restricts accessor/mutator access
• Proxy
  An object representing another object

These design patterns are all about Class's objects communication. Behavioral patterns are those patterns that are most specifically concerned with communication between objects.

• Chain of responsibility
  A way of passing a request between a chain of objects
• Command
  Encapsulate a command request as an object
• Interpreter
  A way to include language elements in a program
• Iterator
  Sequentially access the elements of a collection
• Mediator
  Defines simplified communication between classes
• Memento
  Capture and restore an object's internal state
• Null Object
  Designed to act as a default value of an object
• Observer
  A way of notifying change to a number of classes
• State
  Alter an object's behavior when its state changes
• Strategy
  Encapsulates an algorithm inside a class
• Template method
  Defer the exact steps of an algorithm to a subclass
• Visitor
  Defines a new operation to a class without change

Criticism

The concept of design patterns has been criticized by some in the field of computer science.

Targets the wrong problem

The need for patterns results from using computer languages or techniques with insufficient abstraction ability. Under ideal factoring, a concept should not be copied, but merely referenced. But if something is referenced instead of copied, then there is no "pattern" to label and catalog. Paul Graham writes in the essay Revenge of the Nerds.

Peter Norvig provides a similar argument. He demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan.

Lacks formal foundations

The study of design patterns has been excessively ad hoc, and some have argued that the concept sorely needs to be put on a more formal footing. At OOPSLA 1999, the Gang of Four were (with their full cooperation) subjected to a show trial, in which they were "charged" with numerous crimes against computer science. They were "convicted" by ⅔ of the "jurors" who attended the trial.