Presentation is loading. Please wait.

Presentation is loading. Please wait.

Beware of bugs in the above code; I have only proved it correct, not tried it.

Similar presentations


Presentation on theme: "Beware of bugs in the above code; I have only proved it correct, not tried it."— Presentation transcript:

1 Beware of bugs in the above code; I have only proved it correct, not tried it.

2 Religious Studies 313 – Advanced Programming Topics

3 Why Use Factories? Pizza pie = new DeepDish(); pie = new Garlic(pie); pie = new Onion(pie); pie

4 Simple Factory Pattern Pizza pie = PizzaFactory.createPizza(type, toppings); Pizza createPizza(String type, String[] toppings) { Pizza ret; if (type.equals(“DeepDish")) ret = new DeepDish(); else ret = new Cracker(); for (String s : toppings) { if (s.equals(“Garlic")) ret = new Garlic(ret); else if (s.equals(“Onion")) ret = new Onion(ret); else if (s.equals(“Fish")) ret = new Anchovy(ret); else ret = new Cheese(ret); } return ret; }

5 Simple Factory Overview  Single method to perform instantiation  Method often defined in class of its own  Could also make method static*  Replace new with calls to simple factory  Simple factory contains all new commands  Update with each new class of same type * Do not make this method static

6 Simple Factory Overview  Really, really helpful pseudo-pattern  Easy to write  Isolates code that often needs to change  Remaining code relies on abstractions  Simplifies using new subclasses in program  Simple Factory pattern needs little design  Needs only factory class & type(s) it instantiates

7 Simple Factory UML  Clients call method in SimpleFactory  AbstractProduct is returned to client  Does not know which ConcreteProduct it is  May not know ConcreteProduct s exist  Can invisibly change ConcreteProducts

8 Speaking of Pizza Toppings Otto von Bismarck [Classes] are like sausages. It's better not to see them being made.

9 In The Beginning… Creator Product

10 Problem with Simple Factory

11 Design like you code; Start with the abstractions Design like I code; Start with the abstractions Design like someone good codes; Start with the abstractions Dependency Inversion

12 Bottoms-Up!

13 Design to Concept, Too  Simple factory created as need arises  Developer notices many like classes created  Methods becoming bloated with options  Prescient engineer creates future options  These all start and end with the classes  Simple factory used as means to an end  No work conceptualizing concrete classes  No design work going into Simple Factory

14 Problem with Simple Factory

15 What if…

16 Simple Factory public class PizzaFactory { Pizza createPizza(String type, String[] toppings) { Pizza ret; if (type.equals(“DeepDish")) ret = new DeepDish(); else ret = new Cracker(); for (String s : toppings) { if (s.equals(“Garlic")) ret = new Garlic(ret); else if (s.equals(“Onion")) ret = new Onion(ret); else if (s.equals(“Fish")) ret = new Anchovy(ret); else ret = new Cheese(ret); } return ret; }

17 Factory Method Pattern public abstract class PizzaFactory { Pizza createPizza(String type, String[] toppings) { Pizza ret = createPizzaType(); for (String s : toppings) { if (s.equals(“Garlic")) ret = new Garlic(ret); else if (s.equals(“Onion")) ret = new Onion(ret); else if (s.equals(“Fish")) ret = new Anchovy(ret); else ret = new Cheese(ret); } return ret; } abstract Pizza createPizzaType(); }

18 Factory Method Pattern public class DeepDishFactory extends PizzaFactory { Pizza createPizzaType() { return new DeepDish(); } } public class ThinCrustFactory extends PizzaFactory { Pizza createPizzaType() { return new Cracker(); } }

19 Factory Method UML  Clients call method in AbstractFactory  May not know ConcreteFactory they have

20 Factory Method Process  AbstractCreator defines factory  Can be interface or abstract class  Does not actually instantiate any Product s  ConcreteCreator s create instances  ConcreteCreator for each type of Product  Use multiple creators for parallel hierarchies  Creates two sets of parallel hierarchies  DeepDish & Cracker product lines  DeepDishFactory & ThinCrustFactory creator

21 Factory Method Intent  Only use interfaces & abstract classes for:  Variables  Fields  Parameters  Statics  Banish required concreteness to perimeters  Factory methods  Where performance is critical  Code passing the “What would _______ do?” test

22 For Next Lecture  Lab #4 available on web/Angel  Due before next lab (Tues. 2/26) ‏  I will be available during lab time next week  First set of pattern reports due on 8AM Wed.  This time: Debbie, Jake, Katey, Matt S. & Ryan  Read pages 144 - 162 in the book  How can we easily enable skinnable applications?  Could I make even odder religious references?


Download ppt "Beware of bugs in the above code; I have only proved it correct, not tried it."

Similar presentations


Ads by Google