• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Design patterns
 

Design patterns

on

  • 1,426 views

 

Statistics

Views

Total Views
1,426
Views on SlideShare
1,426
Embed Views
0

Actions

Likes
1
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Design patterns Design patterns Presentation Transcript

    • Design Patterns Abhishek Chatterjee
    • Agenda
      • Introduction
      • Coding practices
      • Is there room for improvement?
      • Object Oriented Analysis and Design
      • Design Patterns – an intro
      • An orientation example – Strategy Pattern
      • Inversion of Control – Dependency Injection
      • Mediator Pattern
      • Quick look at a practical example
    • Introduction
      • This is nothing about a new technology or a framework
      • This is all about how and where to write code so that
        • The solution is scalable
        • The solution is flexible
        • Chances of errors are reduced
        • The solution is imagined in a more real-world way
      • We identify some good practices and call them names
    • Coding practices
      • Following naming conventions
      • Writing commented code
      • Wrapping code in regions
      • Etc. etc. etc.
      What is beyond it?
    • Object Oriented Analysis and Design
      • We all know what is OOP
      • Figuring how good OOP will help our solution is OOAD
    • Design Patterns – an intro
      • What are design patterns?
      • A pattern of OOAD principle which can be applied to multiple problem scenarios is called a Design Pattern
      • Design Pattern is nothing but a good OOAD design and given a name
    • An Orientation Example – Strategy Pattern Duck quack() swim() abstract display() MallardDuck display() RedheadDuck display() Lots of other types of ducks
    • An Orientation Example – Strategy Pattern Duck quack() swim() abstract display() fly() MallardDuck display() RedheadDuck display() Lots of other types of ducks
    • An Orientation Example – Strategy Pattern Duck quack() swim() abstract display() fly() MallardDuck display() RedheadDuck display() Lots of other types of ducks
    • An Orientation Example – Strategy Pattern Duck quack() swim() abstract display() fly() MallardDuck display() RedheadDuck display() Yay!! I can fly too!!! RubberDuck display()
    •  
    • Hey Abbey-Shack…. If you want to try Monster.com’s resume services, now is the time.
    • Who is going to rescue me now? <<Interfaces>> !!! Yes!!! That’s it! I make an IFlyable interface and RubberDuck doesn’t get to implement it… MallardDuck <<IFlyable>> display() RedheadDuck <<IFlyable>> display() RubberDuck //You can’t fly! display() They can’t see me happy 
    • I… I… I… I have a Question! SimCorp simulates 50 ducks… are you saying you are going to write 50 fly methods? What if there is a change in flying style and it effects 20 ducks… will all 20 ducks change? I am losing money you know…
    • I thought she was non-technical…
      • Well here is my situation
      • I can’t put the fly() method in the base class
      • If I use interface, I can’t reuse code
      • Alright, so this calls for a dependency split
      • Flying is a behavior and should be separate from the Duck object
      • Flying behaviors could be reused on different objects
      • Different ducks could fly in different ways
    • Strategy Pattern in Action Duck quack() swim() abstract display() MallardDuck IFlyBehavior:FlyWithWings display() RubberDuck IFlyBehavior: DontFly display() IFlyBehavior fly() FlyWithWings FlyWithRocket DontFly
    • Inversion of Control – Dependency Injection
      • Creating a dependency between two objects
      • Catering to that dependency without affecting scalability of the solution
      • How does MallardDuck know if it should use FlyWithWings behavior? Simple:
      • public class MallardDuck : Duck
      • {
        • IFlyBehavior flyBehavior;
        • public MallardDuck()
        • {
          • this.flyBehavior = new FlyWithWings();
        • }
      • }
    • The problem with that is…
      • When there is a defaulter…
      • For example, let’s take RubberDucks
      • public class RubberDuck : Duck
      • {
        • IFlyBehavior flyBehavior;
        • public RubberDuck()
        • {
          • this.flyBehavior = new DontFly();
        • }
      • }
      So you thought I couldn’t fly? Wheeee… Look at my rocket boosters!
    • Constructor Injection
      • public class RubberDuck : Duck
      • {
        • IFlyBehavior flyBehavior;
        • public RubberDuck(IFlyBehavior flyBehavior)
        • {
          • this.flyBehavior = flyBehavior;
        • }
      • }
      • Now anyone instantiating a Duck object needs to inject the dependent class, solving the design problem of the Rubber duck with boosters
    • Q & A
    • Thank You