Design Patterns

Why read if you can watch? Watch design patterns video tutorial In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in 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.

Uses of Design Patterns

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. Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem. In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.

Creational design patterns

This design patterns is all about class instantiation. This pattern can be further divided into classcreation patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.

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

Structural design patterns

This design patterns is 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 objects 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

Behavioral design patterns

This design patterns is 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.

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.

Does not differ significantly from other abstractions

Some authors allege that design patterns don't differ significantly from other forms of abstraction, and that the use of new terminology (borrowed from the architecture community) to describe existing phenomena in the field of programming is unnecessary. The Model-ViewController paradigm is touted as an example of a "pattern" which predates the concept of "design patterns" by several years. It is further argued by some that the primary contribution of the

Design Patterns community (and the Gang of Four book) was the use of Alexander's pattern language as a form of documentation; a practice which is often ignored in the literature.

Creational patterns
01 In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. The basic form of object creation could result in design problems or added complexity to the design. Creational design patterns solve this problem by somehow controlling this object creation.

02

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

Rules of thumb
1. Sometimes creational patterns are competitors: there are cases when either Prototype or

Abstract Factory could be used profitably. At other times they are complementory: Abstract Factory might store a set of Prototypes from which to clone and return product objects, Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementation.

2. Abstract Factory, Builder, and Prototype define a factory object thats responsible for

knowing and creating the class of product objects, and make it a parameter of the system. Abstract Factory has the factory object producing objects of several classes. Builder has the factory object building a complex product incrementally using a correspondingly complex protocol. Prototype has the factory object (aka prototype) building a product by copying a prototype object. 3. Abstract Factory classes are often implemented with Factory Methods, but they can also be implemented using Prototype. 4. Abstract Factory can be used as an alternative to Facade to hide platform-specific classes. 5. Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately. 6. Builder is to creation as Strategy is to algorithm. 7. Builder often builds a Composite. 8. Factory Methods are usually called within Template methods. 9. Factory Method: creation through inheritance. Prototype: creation through delegation. 10. Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed. 11. Prototype doesnt require subclassing, but it does require an Initialize operation. Factory Method requires subclassing, but doesnt require Initialize. 12. Designs that make heavy use of the Composite and Decorator patterns often can benefit from Prototype as well.

Why design patterns work

A design pattern is a recurring solution to a common problem. A solution for a problem that has been found to work well over and over. Such a solution over time becomes a convention.
Categorized in: introduction, design patterns, conventions, pattern definition, pattern definitions Conventions are not limited to the online world, but is to be found everywhere in real world as well. As we grow up, we learn the convention of pushing a door-handle down to open its door and driving on the right side of the road (depending on what country you live in) to avoid nasty collisions. We learn to cross a street when the light is green and hold when its red. We learn how to read a newspaper by learning the conventions of page layouts and formatting to easier scan its information. In this way we can find the stories we are interested in quickly and efficiently. Conventions all start off as an idea good enough to be imitated by others. Similarly, design conventions on the web stem from ideas on one website good enough to be imitated by another. As more websites copy an idea, it is exposed to the public as more and more see it. When it has

reached a critical mass, it needs no explanation. This is when it has become a convention. The idea that solved a problem becomes a convention if it is common enough. If it also has a good amount of quality, it is a design pattern worth talking about. Conventional design patterns provide a reassuring sense of familiarity to the user. When one is spotted the user immediately knows how it works and what it does. No unnecessary time needs to be spent to figure out how things work. The user does not need to think. Take advantage of design patterns and the conventions embedded in them. Using design patterns may not win you the pulitzer prize for new and innovative thinking, but they will help you reduce friction and thus provide better usability. Innovate when you know you have the better idea, but use design patterns and conventions in all other cases. Its all about the execution.

Benefits: 1. enable large scale reuse of S/W 2. Helps in improve developer communication 3. capture expert knowledge and design trade-offs and make expertise widely available Drawbacks: 1.Do not lead to direct code reuse 2. Complex in nature 3. they are deceptivrly simple 4. they are validated by experince and discussion