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.

Software Design Patterns - Overview and Rant

General reusable solutions to commonly occurring problems in software design, made popular by the 1994 book by the "Gang of four". Lately I am leaning towards dismissing them as buzz-words that wanna-be l33t hax0rs use to impress/confuse and a favourite question of interviewers. More and more patterns that I come across in reading seem to be post-hoc descriptions of designs that I or other developers have used frequently without attributing a spiffy name to. For example, the Strategy pattern - a design pattern whereby algorithms can be selected at runtime, implemented using concrete strategy classes implementing a strategy interface. How is that different from polymorphism? If anything it is a subset of polymorphism and adds nothing new. And the Iterator pattern??

I admit I do find some pattern identification useful. For example, the Facade - exactly what it sounds like, defines a higher-level interface that makes a subsystem easier to use.

Although the Singleton is still often identified as a pattern, there is growing belief that it should really be classed as an anti-pattern. Some of the drawbacks identified include the following:

• The limitations it introduces may be unnecessary, ie: a sole instance may not actually be required in a given situation. Additionally these limitations may cause threading issues.
• Singletons introduce global state into applications resulting in dependencies in the design being hidden inside the code, rather than obvious dependencies highlighted by method parameters for example.
• For purists, Singletons mix two different responsibilities in the same class, one of them being the control over the number of instances of itself. This may be better handled using a Factory to encapsulate creation and limit instances.

In short, although I think the study of design patterns (and anti-patterns) is great for building up a budding developer's abilities, I am somewhat sceptical about 1) the introduction of new terminology to describe existing simple solutions to a problem, that really don't require another name, and 2) the proliferation of patterns in areas where something simpler and more customised would be a lot easier to understand and maintain.