Your browser doesn't support the features required by impress.js, so you are presented with a simplified version of this presentation.

For the best experience please use the latest Chrome, Safari or Firefox browser.

Design Patterns
Rupesh Bhochhibhoya
Object Oriented Programming
Encapsulation
Inheritance
Abstraction

Only talk to your friends A class should have only one reason Single Responsibility Principle
Common closure principle  Don’t call us we’ll call you. Encapsulate what varies Program to interface, not implementation
Classes should be open for extension but closed for modification Depend on abstractions, do not depend on concreted classes: 
Dependency Inversion Principle Favor Composition over Inheritance Strive for loosely coupled designs between objects that interact.

Object Oriented Design
??
OOD principles
Alphabets Words Sentences tense, noun verb pronoun Essay articles books
Polymorphism
------------------------------
- Recurring set of situations
- Similar Goal and Constraints
- How-to-guide on OOD 
It worked,
      so documented and gave it a NAME
"A solution to a problem in a context"
Blueprints
Reusability
Common Vocabulary
Speeds up SDLC
Manageable
Expandable
...
Why use
Scenario 1
Light and Switch
Bridge Pattern
"Decouple an abstraction from its implementation
                 so that the two can vary independently"
Scenario 2
Football is Here
Strategy Pattern
"Define a family of algorithms, encapsulate each one, and make them interchangeable.
Strategy lets the algorithm vary independently from the clients that uses it."
Scenario 3
Football is Here, 
Everyone observing ball
Observer Pattern
"Define a one-to-many dependency between objects so that when
     one object changes state, all its dependents are notified
        and updated automatically."
Scenario 4
 One Football
Singleton pattern
"Ensure a class has only one instance,
        and provide a global point of access to it."
Categories
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

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 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

Private Class Data: Restricts accessor/mutator access

Proxy: An object representing another object


Behavioral Patterns

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
Keep in mind...
"Shoot for practical extensibility. Don’t provide hypothetical generality;
be extensible in the ways that matter." –
Richard Helm
"Go for simplicity and don’t become over-excited. If you can come up with
 a simpler solution without using a pattern, then go for it" –
Ralph Johnson
"Patterns are tools not rules; they need to be tweaked and adapted to
your problem" –
Erich Gamma
"Walking on water and developing software from a
specification are easy if both are frozen.“ –
Edward V. Berard
Think abstract

Use a spacebar or arrow keys to navigate