Overview of popular software design patterns

Singleton

Ensure that only one instance of a class is created. To implement this, make the constructor protected (unit tests may need to access it), have a private static member which is an instance of itself, and have a get method that instantiates the class only if one does not already exist. 

Use of singletons can be abused. They are a little like global variables. Systems relying on global state hide their dependencies. Some arguments against using it: 

• It promotes tight coupling between classes 
• It violates the single responsibility principle - a class should not case whether it is a singleton.

They can be fairly safely used when they don't contain any mutable state. An example of an appropriate use of a singleton may be a global resource manager.

Factory

Creates objects without exposing the instantiation logic to the client and refers to the newly created object through a common interface. A simple implementation would be to have an interface and some implementing classes. The factory will return an instance of the superclass. Which subclass it is will depend on parameters passed in to the creation/get method.

Factory Method

Defines an interface for creating objects, but lets subclasses decide which class to instantiate and refers to the newly created object through a common interface.

MVC

Separates the model, view, and controller, or presentation, logic, and data.

DAO

Abstracts and encapsulates all access to the data source. The DAO manages the connection with the data source to obtain and store data.

Facade

Provides a unified, convenient interface to a set of existing interfaces, potentially hiding some components/interfaces. It provides flexibility to change/replace "hidden" subsystems including interfaces.

Prototype
Specifies the kinds of objects to create using a prototypical instance, and creates new objects by copying this prototype.

Strategy
Defines a family of algorithms, encapsulating each one and making them interchangeable. The strategy pattern lets the algorithm vary independently from clients that use it.

Observer
Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Command

Encapsulates a request in an object allowing the parameterisation of clients with different requests and allows saving the requests in a queue.

Visitor
Represents an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Decorator
Adds additional responsibilities dynamically to an object.

Flyweight
Uses sharing to support a large number of objects that have part of their internal state in common where the other part of their state can vary.

Proxy
Provides a placeholder for an object to control references to it.

Bridge
Increases flexibility by letting abstraction and implementation evolve independently. This is achieved by having separate layers for abstraction and implementation, with a fixed implementation interface.