Design Patterns

Design Patterns

Generic solutions to common problems encountered in object oriented software design. Patterns are language and domain independent strategies for solving common OO design problems

• Abstraction: focuses upon essential characteristics of the object relative to perspective(domain) of the user.

• Encapsulation: Hides internal details of an object.

• Abstraction and Encapsulation are complementary concepts. Abstraction focuses on the behaviour of an object and Encapsulation focuses on implementation that gives rise to this behaviour.

• Modularity: is the property of dividing the system into set of cohesive and loosely coupled modules.

• Namespaces can be used to logically group related classes into one logical structure.

• Hierarchy is the ranking or ordering of abstractions.( eg1. "is-a" Sorting base class and concrete different sorting algo inherits from base)(eg2: "part-of") "part-of" : Aggregation or containment.

• Aggregation: inner objects lifetime is not controlled by outer object.Eg if classroom is destroyed student will be part of new classroom.(non filled diamond)

• Containment: inner object lifetime is controlled by outer object. Eg if window is closed its button also gets closed.(filled diamond)

• Polymorphism: All movable objects can move. Each object will move in a different way for same message.

1. Compile time polymorphism: types will be resolved at compile time.eg overloading and function templates.
2. Run time polymorphism: types will be resolved at run time. eg virtual functions

Important principles to be followed during software design:

• Single responsibility principle:There should never be more than one reason for a class to change.

• Open closed principle:Module should be open for extension but closed for modification.(eg. through polymorphism client can use any of the subclasses of the abstraction without directly depending on them)

• Liskov substitution principle: Functions that use pointers or references to the base class must be able to use objects of derived class without knowing them.

• Dependency Inversion principle:High level modules should not depend on low level modules. both should depend upon abstractions.

1. Abstractions should not depend on the details.Details should depend on abstractions.
2. Program to interface not to implementation.
3. No variable should hold a reference to concrete class
4. No class should derive from a concrete class.

• Interface segregation principle:Many client specific interfaces are better than one general purpose interface. client should not be forced to depend on methods they do not use.

1. Interfaces can be broken up into group of functions and each group will server different set of clients
2. Inheritence: White box reuse.Implementation of parent class can be easily overriden by derived classes.
3. Use inheritence for representing common behaviour.Avoid inheriting from concrete classes.
4. Composition: object composition is another form of reuse. Black box reuse.No internal details of object are visible.Composition can be defined dynamically at runtime through references or pointers to objects.

Design patterns can be of following types:

1. Creational  Object creation.
2. Structural deal with composition of objects and classes.
3. Behavioural  interaction between objects or classes.

Creational Patterns
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
Prototype	A fully initialised instance to be copied or cloned
Singleton	A class of which only a single instance can exist

Structural Patterns
Adapter	Match interfaces of different classes
Bridge	Separates an object’s 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
Proxy	An object representing another object

Behavioural Patterns
Chain of Resp.	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
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

Following are the hyperlinks to all 23 Design Patterns:

Creational Patterns
Abstract Factory	Abstract Factory Method Design Pattern
Builder	Builder Design Pattern
Factory Method	Factory Method Design Pattern
Prototype	Prototype Design Pattern
Singleton	Singleton Design Pattern

Structural Patterns
Adapter	Adapter Design Pattern
Bridge	Bridge Design Pattern
Composite	Composite Design Pattern
Decorator	Decorator Design Pattern
Facade	Façade Design Pattern
Flyweight	Flyweight Design Pattern
Proxy	Proxy Design Pattern

Behavioural Patterns
Chain of Resp.	Chain of responsibility Design Pattern
Command	Command Design Pattern
Interpreter	Interpreter Design Pattern
Iterator	Iterator Design Pattern
Mediator	Mediator Design Pattern
Memento	Memento Design Pattern
Observer	Observer Design Pattern
State	State Design Pattern
Strategy	Strategy Design Pattern
Template Method	Template Method Design Pattern
Visitor	Visitor Design Pattern