Design Pattern
In software engineering, the design pattern is a solution to commonly occurring problem in the software design. A design pattern isn’t a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. They are categorized in three groups: Creational, Structural, and Behavioral
Creational Design Pattern
This pattern deals with class instantiation only. This is further divided in to class creation and object creation patterns. The class creation pattern deals with proper use of inheritance where as object creational pattern use delegation to do the job.
Abstract Factory:
Provide an interface for creating families of related or dependent objects without specifying their concrete classes. E.g. stamp of automobile parts
Builder Design Pattern:
Separate the construction of a complex object from its representation so that the same construction process can create different representations. E.g. Fast food chain (kids meal and adult meal). Decide if a common input and many possible representations (or outputs) is the problem at hand.
Factory Method:
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Object Pool:
Object pooling can offer a significant performance boost; it is most effective in situations where the cost of initializing a class instance is high, the rate of instantiation of a class is high, and the number of instantiations in use at any one time is low.
Prototype Design Pattern:
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.
Singleton Pattern:
Ensure a class has only one instance, and provide a global point of access to it
Encapsulated “just-in-time initialization” or “initialization on first use”.
Structural Design Patterns:
The design pattern is related to class and object composition. Structural object-patterns define ways to compose objects to obtain new functionality.
Adapter Design Pattern:
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn’t otherwise because of incompatible interfaces. Shape > Ractangle > Legacy Ractangle
Bridge Design Pattern:
Decouple an abstraction from its implementation so that the two can vary independently.
Publish interface in an inheritance hierarchy, and bury implementation in its own inheritance hierarchy.
Facade
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
Proxy Design Pattern:
Provide a surrogate or placeholder for another object to control access to it.
Use an extra level of indirection to support distributed, controlled, or intelligent access.
Behavioral design pattern:
This design pattern is about class’s object’s communication.
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
The C++ and Java standard library abstraction that makes it possible to decouple collection classes and algorithms.
Observer Design Pattern:
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. The “View” part of Model-View-Controller.
Critisim:
Some languages do not need design patterns:
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
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.
Leads to inefficient solutions
The idea of a design pattern is an attempt to standardize what are already accepted best practices. In principle this might appear to be beneficial, but in practice it often results in the unnecessary duplication of code. It is almost always a more efficient solution to use a well-factored implementation rather than a “just barely good enough” design pattern.
Ref: http://sourcemaking.com/design_patterns
