Design patterns

13
Presentation on Design Patterns Design Patterns By Samundra Shrestha

description

Introduction to Design Patterns by Samundra Shrestha

Transcript of Design patterns

Page 1: Design patterns

Presentationon

Design PatternsDesign Patterns

By Samundra Shrestha

Page 2: Design patterns

Patterns

Each pattern describes a problem which occurs over and over again in our environment and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same twice.

- Christopher Alexander, TheTimeless Way of Building, 1979

So what are patterns?

Page 3: Design patterns

What are Patterns, really?

Patterns catalog solutions to categories of problems

They consist ofThey consist of

A name

A solution to a problem

A description of the solution

An assessment of the pros and

cons of the pattern

Page 4: Design patterns

What are Patterns Not?

1. An algorithm.

2. An implementation.

3. The same every time you see them.

Page 5: Design patterns

Introduction to Design PatternsGang of Four (GOF) Erich Gamma, Richard Helm, Ralph Johnson,

and John Vlissides Authors of the original Design Patterns book

Problem in software design What – business and functionality requirements How – particular design to meet the requirements Work – Actual implementation, How put into practice.

Page 6: Design patterns

Principal and Strategies

improve abilities as analyst and designer.

tackle situation in which no design pattern can be

applied or design pattern has not been discovered yet.

Open Closed Principle

Dependency Inversion Single Responsibility Policy

Why ?

Page 7: Design patterns

Contextual Design

Open Closed Principle (OCP)

"Modules, methods, classes should be open for extension, while closed for modifications."

Loose Coupling

Encapsulation

Page 8: Design patterns

Dependency Inversion Principle

Depend on the abstractions

Higher level module should not depend on lower

level module. Both high and low level should depend

on abstractions

Abstraction should not depend on details. Details

should depend on abstractions.

Page 9: Design patterns

CategorizationCreational Patterns

Single instance in the whole application/platform

Behavioral Patterns

Structural Patterns

Abstract Factory, Builder, Factory Method, Prototype, Singleton

Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy

Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, Method, Visitor

Page 10: Design patterns

Patterns by ExamplesSingleton Patterns

Problem : Ensure a class has only one instance available in the system anytime.

Output:

Design Patterns Example

Page 11: Design patterns

Factory Pattern

dynamically create instances of multiple classes based on runtime input.

Output:

This is system generated messageThis is console generated message

Patterns by Examples

Page 12: Design patterns

Decorator Patternbest suited for altering or decorating portions of an existing object’s content or functionality without modifying the structure of the original object.

Output :

The CD contains the following tracks: 1) what-it-means. 2) brr. 3) good-bye.

Patterns by Examples

Page 13: Design patterns

Thank you :)