As per WIKI, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
Why do we need them?
Well, rather than having to re-invent the wheel, we can re-use an existing solution recognized across organizations as something that simply works. Since it is well documented, it is comparatively easier to solve the problem and solution in our mind.
How many are there?
There is no definitive list of the patterns. People working on various challenges document them and spread the word about a possible solution. Over a period of time, this solution is recognized as a standard pattern for solving a particular problem. Obviously the most common patterns are the ones for Gang of Four or you can also look at Wikipedia for design patterns.
Design pattern is divided based on purpose and scope.
Purpose
|
||||
Creational
|
Structural
|
Behavioural
|
||
Scope
|
Class
|
Factory Method
|
Adapter
|
Interpreter
Template Method
|
Object
|
Abstract Factory
Builder
Prototype
Singleton
|
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
|
Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor
|
Design patterns are divided into three fundamental groups.
- Behavioral patterns are those patterns that are most specifically concerned with communication between objects.
- All of the creational patterns deal with the best way to create instances of objects. This is important because your program should not depend on how objects are created and arranged.
- Structural patterns describe how classes and objects can be combined to form larger structures. The difference between class patterns and object patterns is that class patterns describe how inheritance can be used to provide more useful program interfaces. Object patterns, on the other hand, describe how objects can be composed into larger structures using object composition, or the inclusion of objects within other objects.
Each fundamental groups are further divided into multiple ways:
Creational Patterns
|
|
Creates
an instance of several families of classes
|
|
Separates
object construction from its representation
|
|
Creates
an instance of several derived classes
|
|
A
fully initialized instance to be copied or cloned
|
|
A
class of which only a single instance can exist
|
Structural Patterns
|
|
Match
interfaces of different classes
|
|
Separates
an object’s interface from its implementation
|
|
A tree structure of simple and composite
objects
|
|
Add responsibilities to objects dynamically
|
|
A
single class that represents an entire subsystem
|
|
A fine-grained instance used for efficient
sharing
|
|
An
object representing another object
|
Behavioral Patterns
|
|
A way of passing a request between a chain
of objects
|
|
Encapsulate a command request as an object
|
|
A way to include language elements in a
program
|
|
Sequentially access the elements of a
collection
|
|
Defines simplified communication between classes
|
|
Capture and restore an object's internal
state
|
|
A way
of notifying change to a number of classes
|
|
Alter an object's behavior when its state
changes
|
|
Encapsulates an algorithm inside a class
|
|
Defer the exact steps of an algorithm to a
subclass
|
|
Defines a new operation to a class without
change
|
Useful websites:
GoF Patterns
DoFactory
No comments:
Post a Comment