Downloaded 51 times
Uploaded byJulie Iskander
Design Pattern lecture 2
The document outlines design patterns as solutions to common problems that aid in organizing objects for extendability and modification. It details the history, learning methods, and classifications of design patterns, particularly according to the Gang of Four (GoF). Specific creational design patterns such as Singleton, Factory Method, and Abstract Factory are discussed, including their characteristics and implementation strategies.
More Related Content
Similar to Design Pattern lecture 2
More from Julie Iskander
Design Pattern lecture 2
- 1. Design Pattern By Julie Iskander MSc. Communication and Electronics
- 2. Outlines Lecture 2 • What is Design Patterns? • History of Design Patterns • How to learn Design Patterns? • Design Patterns Classifications acc. to GoF • Creational DP: • Singleton • Factory Method • Abstract Method • Builder • Prototype
- 3. What is DesignPattern • A pattern is a solution to a common problem, • NOT a code solution ready for copy-and-paste but a best practice, a useful abstraction, and a template for solving categories of problems.
- 4. What is DesignPattern • Design Patterns are frequently used ways of organizing objects to make solutions easier to extend and modify • Design Patterns name and describe effective solutions for common problems • Design Pattern help a designer get a design right faster. • Never reinvent the wheel.
- 5. What is DesignPattern • “Each pattern describes a problem which occurs over and over again, and then describes the core of the solution in such a way that you can use this solution many times without ever doing it the same way twice”, Christopher
- 6. History of DesignPattern • Dr. Christopher Alexander (in civil engineering), in1977, A Pattern Language. • In 1978–79, Prof. Trygve Reenskaug (in computer science), wrote “The design pattern: Model-View– Controller (MVC)”. • In 1995, a catalog of 23 design patterns by Drs. Gamma, Helm, Johnson, and Vlissides “Gang of Four” (GoF), “Design Patterns: Elements of Reusable Object- Oriented Software (Addison-Wesley, 1995)”.
- 7. How to learnDesign patterns ? The best way to use patterns is to load your brain with them and then recognize places in your designs and existing applications where you can apply them
- 8. “Designing OO softwareis hard and designing reusable OO software even harder”, Erich Gamma Experience Reusing solutions that worked before Knowing patterns that worked in the past make designer more productive and creating flexible and reusable designs
- 9. Instead of codereuse, with design patterns you get experience reuse
- 10. Advantages of learningDesign Pattern • It helps us to communicate in an efficient manner, creates a common vocabulary • It enables us to discuss low-level implementation in a high-level, abstract manner. • It enables us to apply a proven solution (experience reuse) • It helps extendibility and avoid solution redesign • It help present design alternatives if found. • It can help improve maintenance and documentation
- 11. Design Pattern elements •Pattern Name • Problem : When to apply? Problem and Context • Solution • Consequence : results, trade offs of applying it
- 12.
- 14. MVC • What ,Where • a requirement to vary perspectives or views (output) without changing the underlying information source (model). • Why • it is more manageable and less expensive to encapsulate change in a set of controller objects than it is to disfigure the model object through constant reengineering.
- 15. MVC • How •Encapsulating the client requirements in a controller object that transposes the information from the model object into the variety of formats required by the client. • a model object (model) • a view interface (IView), or abstract class, if you prefer; • Deriving any number of views (GraphView and BarView classes) from the interface; • creating a controller object (controller), to represent each view; and then wiring up the functionality.
- 16. Design Patterns according tothe GOF
- 17. DP Classifications • Accordingto scope Class Object Deals with relationships Deals with objects between classes and their relationships that can be subclasses changed at runtime, dynamically Done by inheritance
- 18. DP Classifications • Accordingto purpose Creational Structural Behavioral Gives program the Deals with the Characterizes the flexibility in composition of way classes and deciding which classes and objects objects interact and object to create. to create larger distribute When and how to structures responsibilities create objects Or add functionalities
- 19. DP Classifications • Accordingto purpose Creational Structural Behavioral Singleton Adapter (Class Chain of Responsibility Factory Method Pattern) Command (Class Pattern) Bridge Iterator(Class Pattern) Abstract Factory Composite Mediator Builder Decorator Memento Prototype Façade Observer Flyweight State Proxy Strategy Template Method (Class Pattern) Visitor Interpreter
- 20.
- 21.
- 22. Singleton (object – Creational DP) • What, Why • A class has one and only one instance created • How • private constructor
- 23.
- 24. Singleton (object – Creational DP) • Notes: • Can permit a variable # of instances
- 25. Factory method (Class – Creational DP) There is more to making objects than just using the new operator. Instantiation is an activity that shouldn’t always be done in public and can often lead to coupling problems.
- 26. Factory method (Class – Creational DP) • What • A design that defines an interface for creating objects and delegates the choice of what objects to create to subclasses. • A creator class is required to be decoupled from creating specific objects. • Why • Flexibility in creating a variety of objects • How • Subclasses, with overridden factory method create specific types, which in turn create content objects.
- 27. Factory method (Class –Creational DP)
- 28. Factory method (Class – Creational DP) • Example • An application with multiple documents • Document type to create depends on specific application • Drawing Application Drawing Documents • Writing Application Writing Documents
- 29. Factory method (Class –Creational DP)
- 30. Factory method (Class – Creational DP) • Another implementation: • Parametrized Factory Method • Parameter specifies the type of product to instantiate • No inheritance in creator class • All Products must implement the product interface
- 31. Abstract Factory DP (object– Creational DP) • What • Client deals with a high-level abstraction for creating families of products while leaving the factory abstraction to deal with coupling the implementation. • A requirement not to couple the client to an implementation that creates sets or families of objects. The pattern enables the client to commit to an interface and avoid commitment to an implementation. • Why • Enhancing the client’s ability to switch between a set or family of objects. • How • Client code has an association with the interface of the factory class. The factory objects create sets of objects .
- 32. Abstract Factory DP (object–Creational DP)
- 33. Abstract Factory DP (object–Creational DP)
- 34. Abstract Factory DP (object–Creational DP)
- 35. Abstract Factory DP (object– Creational DP) • Another Example • Web application that renders a set of controls appropriate for a given web browser type or version.
- 36. Abstract Factory DP (object– Creational DP) • Factories can be singletons • Factory Method for each Product, each ConcreteFactory class overrides it choosing the type of products to create • a new concrete factory subclass for each product family • If many product families used Prototype DP
- 37.
- 38. Builder DP (object– Creational DP) • What • Separate Construction of complex objects from the representation of its parts • Algorithm for creating a complex object should be independent of the parts that make up the object and how they're assembled.
- 39.
- 41.
- 42. Builder DP (object– Creational DP) • Example • A Schedule Builder where there are two types of Schedules(Inhouse or OnSite). • A RTF Converter where there may be text or Images (convert to PDF or ASCII text or……)
- 43. Report #1: Prototype DPwith code example N.B. Hand Written
Editor's Notes
- #4 for example, in a road management pattern language, the problem of cars colliding at an uncontrolled intersection is identified as problem type: uncontrolled intersection.Then a generic solution is found, the result is the creation of the intersection controller design patternfor example, in the previous scenario, we applied the intersection controller design pattern to solve an uncontrolled intersection problem, in which cars collided. However, if we had another uncontrolled intersection problem that involved cars and trains, then we would implement the intersection controller design pattern differently: in the car scenario, we might implement four sets of traffic lights, whereas in the car–train scenario we might implement four sets of traffic lights and a set of crossing gates.
- #5 for example, in a road management pattern language, the problem of cars colliding at an uncontrolled intersection is identified as problem type: uncontrolled intersection.Then a generic solution is found, the result is the creation of the intersection controller design patternfor example, in the previous scenario, we applied the intersection controller design pattern to solve an uncontrolled intersection problem, in which cars collided. However, if we had another uncontrolled intersection problem that involved cars and trains, then we would implement the intersection controller design pattern differently: in the car scenario, we might implement four sets of traffic lights, whereas in the car–train scenario we might implement four sets of traffic lights and a set of crossing gates.
- #6 for example, in a road management pattern language, the problem of cars colliding at an uncontrolled intersection is identified as problem type: uncontrolled intersection.Then a generic solution is found, the result is the creation of the intersection controller design patternfor example, in the previous scenario, we applied the intersection controller design pattern to solve an uncontrolled intersection problem, in which cars collided. However, if we had another uncontrolled intersection problem that involved cars and trains, then we would implement the intersection controller design pattern differently: in the car scenario, we might implement four sets of traffic lights, whereas in the car–train scenario we might implement four sets of traffic lights and a set of crossing gates.
- #7 It discuss a set of 23 design patterns that they observed were commonly found in software development.
- #8 It discuss a set of 23 design patterns that they observed were commonly found in software development.