Downloaded 53 times
Uploaded byAnindya Sundar Paul
Factory Pattern
The document discusses the factory design pattern, particularly its application in a pizza ordering system that allows for dynamic creation of different pizza types without hardcoding each type. It outlines the problems of object creation and how the factory pattern encapsulates this, provides structure, and maintains flexibility for future changes. Key concepts include the isolation of concrete classes, easier product family exchange, and the motivation for using design patterns to rely on reusable solutions.
Factory Pattern
- 1. FACTORY PATTERN presented to Mohammad Samiullah presentedby Anindya Sundar Paul, 07 Zahin Jawad, 31
- 2.
- 3. Scenario 3 Pizza Shop! Pizza orderPizza(){ Pizza pizza = new Pizza(); // bake, box and other stuffs return pizza; }
- 4. Scenario 4 But we haveso many different types of pizza to offer!
- 5.
- 6.
- 7. Solution 7 Pizza orderPizza(String type){ Pizza pizza; if(type.equals(“cheese”)) pizza = new CheesePizza(); if(type.equals(“greek”)) pizza = new GreekPizza(); if(type.equals(“pepperoni”)) pizza = new PepperoniPizza(); // bake, box and other stuffs return pizza; }
- 8.
- 9. Problem 9 New problem. • Addmore pizzas to the menu. • Remove the unpopular ones. • Change the system accordingly.
- 10. Solution 10 Pizza orderPizza(String type){ Pizza pizza; if(type.equals(“cheese”)) pizza = new CheesePizza(); if(type.equals(“greek”)) pizza = new GreekPizza(); if(type.equals(“pepperoni”)) pizza = new PepperoniPizza(); if(type.equals(“clam”)) pizza = new ClamPizza(); if(type.equals(“veggie”)) pizza = new VeggiePizza(); // bake, box and other stuffs return pizza; }
- 11. 11 Nice solution? Realize where thisis going?
- 12. Everlasting Problem 12 Everlasting problem! Thebusiness will keep on changing FOREVER.
- 13. Everlasting Problem 13 New pizza,change code. Remove pizza, change code. New pizza, change code. Remove pizza, change code. It just doesn’t seem right!
- 14. Ultimate solution 14 So what’sthe ultimate solution?
- 15. Design Pattern 15 USE DESIGNPATTERN
- 16. Design Patterns 16 What isdesign pattern? a general reusable solution to a commonly occurring problem
- 17. Design Patterns 17 Why useit? • already solved • reliable solution • time saving
- 18. Design Patterns 18 How doesit relate to our problem? Factory pattern solves the problem we were having!
- 19. Factory Pattern 19 The problemwas about the object creation. Let’s take that part out and encapsulate it!
- 20. Factory Pattern 20 Introducing the FACTORY anew class for the creation of objects
- 21. Factory Pattern 21 public classPizzaFactory { public Pizza createPizza(String type) { Pizza pizza = null; if(type.equals(“cheese”)) pizza = new CheesePizza(); if(type.equals(“pepperoni”)) pizza = new PepperoniPizza(); if(type.equals(“clam”)) pizza = new ClamPizza(); if(type.equals(“veggie”)) pizza = new VeggiePizza(); return pizza; } }
- 22. Factory Pattern 22 We havejust pushed the same problem to another class!
- 23. Factory Pattern 23 Many clientscan use the factory. - a pizza restaurant - a home delivery service
- 24.
- 25. Factory Pattern 25 Abstraction ofthe PizzaStore for franchising Use of factory method instead of factory object
- 26. Factory Pattern 26 public abstractclass PizzaStore { public Pizza orderPizza(String type) { Pizza pizza = createPizza(type); // bake, box and other stuffs return pizza; } abstract Pizza createPizza(String type); }
- 27. Factory Pattern 27 NYPizzaStore orChicagoPizzaStore can implement their own way of creating pizza.
- 28.
- 29. Factory Pattern 29 • definesan interface for creating an object • subclasses decide which class to instantiate Definition
- 30. Factory Pattern 30 Outline • Intent •Motivation • Applicability • Structure • Participants • Collaborations • Consequences
- 31. 31 Factory Pattern Intent •provide an interface • for creating families of related or dependent objects • without specifying the concrete classes
- 32. 32 Factory Pattern Motivation •loosely coupled • a common interface rather than a concrete class • creates dependencies among the steps or ingredients
- 33. 33 Factory Pattern Applicability •independent of creation, composition and representation • configured with one of multiple families of products
- 34. 34 Factory Pattern Applicability •related product objects to be used together • provide a class library of products without revealing implementations
- 35.
- 36. 36 Factory Pattern Participants •Abstract Factory • Concrete Factory • Abstract Product
- 37. 37 Factory Pattern Participants •Concrete Product • Client
- 38. 38 Factory Pattern Collaborations •single instance of concrete factory class to create certain product • different instance of concrete factory to create different products • abstract factory defers to concrete subclasses
- 39. 39 Factory Pattern Consequences •isolation of concrete classes • easier product family exchange • consistency among products • supporting new products is difficult
- 40.
Editor's Notes
- #2 Welcome everyone
- #3 Before diving in, let’s look into a scenario.
- #4 Let’s say we have a pizza shop. When someone orders a pizza, the shop will prepare the pizza by first making a new pizza. So the ordering and then returning the ordered pizza might look like this.
- #5 We see it can make only one type of pizza. But we have so many different types of pizza to offer!
- #6 So it’s a problem! And what do we do when we have a problem? We solve it!
- #7 Let’s say we have three types of pizza to offer. Cheese, Greek and Pepperoni pizza. So how can we change our system so that it can create any one of them according to the customer’s need?
- #8 Here is a probable solution. We take the pizza type as an argument and then based on that instantiate the right type of pizza that our customer wants. Seems like a nice solution!
- #9 But our customers want more varieties. They want more pizzas. So what do we do now?
- #10 So now we have to add the new pizzas to our system so that the customers can order those. Doesn’t seem to be a big deal, right?
- #11 So we remove the condition for the Greek Pizza and add conditions for the new pizzas. Now our system can handle the change in the business.
- #13 The business will always change. It’s the harsh truth. We can do nothing about it.
- #14 The business will always change. It’s the harsh truth. We can do nothing about it.
- #17 In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
- #18 In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
- #19 In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
- #20 In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
- #21 In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
- #22 In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.
- #29 Before diving in, let’s look into a scenario.
- #30 Formal Definition
- #31 This is the outline of our discussion. We are going to look at the intent, motivation, …, consequences
- #32 The definition is a clear indication of the intent. Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
- #33 1)Loosely coupled 2)Clients commit to a common interface rather than a concrete class 3)The factory only creates dependencies among the steps or ingredients of a certain product
- #34 The factory pattern should be used in these scenarios 1. A system should be independent of how its products are created, composed and represented. 2. A system should be configured with one of multiple families of products.
- #35 The factory pattern should be used in these scenarios 3. A family of related product objects is designed to be used together and the designer needs to enforce this constraint. 4. The designer wants to provide a class library of products, and wants to reveal just their interfaces, not their implementations.
- #37 1) AbstractFactory () declares an interface for operations that create abstract product objects. 2)ConcreteFactory () implements the operations to create concrete product objects. 3) AbstractProduct () declares an interface for a type of product object.
- #38 · ConcreteProduct () defines a product object to be created by the corresponding concrete factory. implements the AbstractProduct interface. · Client uses only interfaces declared by AbstractFactory and AbstractProduct classes.
- #39 1) A single instance of a concrete factory class is used to create a certain type of produce. 2) Clients use different instances of concrete factory classes to create different products. 3) The abstract factory defers creation of product objects to its concrete factory subclasses.
- #40 1)Isolates concrete classes 2)It makes exchanging product families easy 3)It promotes consistency among products 4)Supporting new kinds of products is difficult