Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Gof design patterns

  • Login to see the comments

Gof design patterns

  1. 1. GoF Designpatterns - SRIKANTH VAKA ACTIVATE
  2. 2. Agenda  Introduction to GoF Design patterns  Why  What  Where  Types of problems in OOPS  OOD principles  UML notations
  3. 3. Agenda.,  Creational  Factory  Abstract Factory  Singleton  Object Pool  Structural  Adapter  Proxy  Façade  Behavioral  Iterator  Observer  Strategy
  4. 4. Introduction  Each pattern describes a problem which occurs over and over again in software programming environment and then describes the core of solution to that problem.
  5. 5. Introduction  Recipes for the common OO problems.  Code reuse  Open for extension but not for modification  Encapsulate what varies  Single responsibility principle  Program against interface but not against implementation  Avoid Tight coupling
  6. 6. OOD principles  OOD principles to design a class:  SRP: The single responsibility principle  A class should have only one and only one reason to change.  OCP – The open closed principle  Should be able to extend the behavior but not modify the existing behavior.  LSP – The Liskov Substitution principle  Derived classes must be substantial to their base classes.  DIP – The dependency inversion principle  Depend on abstractions, not on concretions.  ISP – The interface Segregation principle  Make fine grained interfaces that are specific to client.
  7. 7. Uses of Design Patterns  Finding appropriate objects.  Determining object granularity.  Specifying object interfaces.  Specifying object implementations.  Programming to an interface not to an implementation.
  8. 8. Question  What is difference or use of below code snippets: Interface ICreditCard{…} Class HDFCCreditCard : ICreditCard {….} ICreditCard _cc = new HDFCCreditCard(); HDFCCreditCard cc = new HDFCCreditCard();
  9. 9. When to go for Interfaces  APIs  Tightly coupled code  Future proofing  Code clarity
  10. 10. UML Introduction  Class representation:
  11. 11. UML Keywords  Encapsulation  Association  Aggregation  Composition  Abstraction  Generalization
  12. 12. Association Vs. Aggregation Vs. Composition Association is a relationship between two classes. Aggregation is the relationship between two classes. Composition is the special type of Aggregation/Association. Association Aggregation Composition
  13. 13. UML Introduction
  14. 14. Scope of Pattern Object level Class level • Deal with object • Deal with relationships relations. between classes and • Relationships are their subclasses. dynamic. • Relationships are static.
  15. 15. Types of Design Patterns • Which can be used while creating objects. Creational • Factory, Abstract Factory, Singleton, Prototype, Builder • Which can be used to combine objects and Structural classes in order to build structured objects. • Adapter, Façade, Proxy, Composite, etc. • Which can be used to build a computation Behavioral and to control data flows. • Iterator, Observer, Strategy, State, etc.
  16. 16. Creational patterns Factory Abstract Creational Factory Singleton
  17. 17. Factory  Defines an interface for creating objects but let sub-classes decide which of those instantiate.  Enables the creator to defer Product creation to a sub-class.
  18. 18. Factory diagram
  19. 19. Factory Example Check Deposit Cash Payment Kiosk Check Payment Cash deposit
  20. 20. Factory Pros & Cons. Pros:  Shields clients from concrete classes.  If a framework follows a Factory pattern, it enables the third party developers to plug-in new products. Cons:  Coding a new product means, writing two classes one for concrete factory and concrete product.  Inheritance based.
  21. 21. ABSTRACT FACTORY  Create instances of classes belonging to different families.  Factory method often used in abstract factory pattern to implement the create methods.
  22. 22. Abstract factory UML
  23. 23. Abstract Factory Facts  Use when a system should be independent of how its products are created, composed and represented.  When a system should be configured with one of multiple families of products.  When a family of objects is designed to be worked together, and you need to enforce this constraint.  If you want to provide a class library of products, and you want to reveal just their interfaces but not implementations.
  24. 24. Example Check Cash Deposit Deposit Book Payment order Payment
  25. 25. Pros./cons. Pros:  Shields clients from concrete classes.  Easy to switch product family at run-time, just change concrete factory. Cons:  Adding a new product means changing factory interface and all concrete factories.
  26. 26. Factory Vs. Abstract Factory  Factory :  Use the Factory Method pattern when there is a need to decouple a client from a particular product that it uses.  Use the Factory Method to relieve a client of responsibility for creating and configuring instances of a product.  Abstract Factory:  Use the Abstract Factory pattern when clients must be decoupled from product classes.  Especially useful for program configuration and modification The Abstract Factory pattern can also enforce constraints about which classes must be used with others. It may be a lot of work to make new concrete factories.
  27. 27. Singleton  A class with only one single possible instance.  Private constructor  Global access
  28. 28. Singleton UML
  29. 29. Example/code  Run-time configuration manager Private static ClassConfigurator GetInstance() { If(instance==null) return new ClassConfigurator(); Else return instance; }
  30. 30. More about Singleton  Thread-safe implementation for multi-threading use.  Lazy instantiation  Early instantiation
  31. 31. Object Pool Pattern  Caching the instances that are costly to create every time.  Also called Object Cache or Resource Cache design pattern.  It is advised to keep all reusable expensive objects that are not currently in use in the container so that they can be managed by one rational policy. To achieve this, the reusable Pool class is designed to be a singleton class.
  32. 32. Object Pool UML
  33. 33. Examples:  Database connection pools.
  34. 34. End of session 1
  35. 35. Structural Patterns Adapter • Translates one interface for a class into a compatible interface. Proxy • Provides a class which limits the access to the original class. Facade • A facade is an object that provides a simplified interface to a larger body of code, such as a class library.
  36. 36. Adapter Pattern  Translates one interface for a class into a compatible interface.  An adapter allows classes to work together that normally could not because of incompatible interfaces, by providing its interface to clients while using the original interface.
  37. 37. Adapter UML
  38. 38. Adapter Example – Data translator
  39. 39. Proxy pattern  Provides a class which limits the access to the original class.  It might be for  Security reasons  To reduce memory foot print  To avoid complex object usage
  40. 40. Proxy UML Diag.
  41. 41. Proxy Example ATM in field Admin @Bank Proxy
  42. 42. Proxy Facts  Introduces a level of indirection when accessing an object.  Can hide the fact that the object resides in different address space.  Can perform optimizations such as creating an object on demand.
  43. 43. Facade Pattern  A facade is an object that provides a simplified interface to a larger body of code, such as a class library.  Make a software library easier to use, understand and test, since the facade has convenient methods for common tasks.  Make the library more readable.  Reduce dependencies of outside code on the inner workings of a library, since most code uses the facade, thus allowing more flexibility in developing the system.  Wraps a poorly designed collection of APIs with a single well- designed API.
  44. 44. Façade UML
  45. 45. Façade Example
  46. 46. End of Session 2
  47. 47. Behavioral Patterns Iterator •An iterator is used to traverse through the container and access the container’s elements. Observer •The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. Strategy •The strategy pattern (also known as the policy pattern) is a particular software design pattern, whereby algorithms can be selected at runtime.
  48. 48. Iterator pattern  An iterator is used to traverse through the container and access the container’s elements.  The essence of the Iterator Factory method Pattern is to "Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation."
  49. 49. Iterator UML
  50. 50. More about Iterator  Robust iterators  Who defines the traversal algorithms?
  51. 51. Observer Pattern  Motivation  Intent  Definition - The observer pattern is a software design pattern in which an object, called the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods.
  52. 52. Observer UML
  53. 53. More about Observer pattern..  Many Subjects to Many Observers  Who triggers the update  Making sure Subject state is self-consistent before notification
  54. 54. Observer Example
  55. 55. Strategy Pattern  Motivation  Intent  Strategy Vs. Creation Pattern
  56. 56. Strategy UML
  57. 57. Strategy Example
  58. 58. More about Strategy..  Passing Data to and from Strategy object.  The strategy design pattern splits the behaviour (there are many behaviours) of a class from the class itself.  This has some advantages, but the main draw back is that a client must understand how the Strategies differ.  Since clients get exposed to implementation issues the strategy design pattern should be used only when the variation in behaviour is relevant to them.
  59. 59. Questions
  60. 60. Thanks  Thanks for listening, if you have any questions mail me at sv250048@ncr.com.  MSN Id: sv250048@ncr.com  Feedback: https://www.recognition4me.com/recognition4me

×