Lecture 14: Programming & Religion

Religious Studies 313 – Advanced Programming Topics Lecture 14:Programming & Religion

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

Simple Factory Pattern Pizza pie = PizzaFactory.createPizza(type, toppings); Pizza createPizza(Stringtype, 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 throw new BadToppingException("Moron!");}return ret; }

Simple Factory Overview

Simple Factory Overview • Instantiation in method to limit instantiation • Often have entire class only with method • Static or instance-based method can be used* • Call simple factory to replace new command • Method contains all newkeeping client code pure • When change occurs, update factory method only

Simple Factory Overview • Instantiation in method to limit instantiation • Often have entire class only with method • Static or instance-based method can be used* • Call simple factory to replace new command • Method contains all newkeeping client code pure • When change occurs, update factory method only * Do not make this method static

Simple Factory Overview • Little design required to use Simple Factory • Within program, much easier to add & use classes • Easy to write since need factory & classes to use • Code that most often needs to change is isolated • Client relies on abstraction simple factory provides

Simple Factory UML • Client code calls method in SimpleFactory • AbstractProduct returned by this method • Specific type unknown, really a ConcreteProduct • Client need not know about ConcreteProducts

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

In The Beginning… Creator Product

Problem with Simple Factory • Approach requires single way to view world • Assimilates everything that comes into contact with it Pizza createPizza(Stringtype, 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); elseret = new Cheese(ret);}return ret; }

Dependency Inversion Design like you code; Start with the abstractions

Dependency Inversion Design like youI code; Start with the abstractions

Dependency Inversion Design like you Isomeone goodcodes; Start with the abstractions

Bottoms-Up! Design like you Isomeone good codes; Start with the abstractions • Begin by finding what ideas have in common • Use for interface or abstract class used by classes • With concepts,design client code & write classes • Concepts limit damage others can do to you • If design include concrete classes, ask questions

Design to Concept, Too • Simple factory created as need arises • Many related classes created for use later • Methods becoming bloated with options • Room for growth wanted even if not used • These cases are all about classes • Means to an end is only reason for simple factory • Concrete classes not conceptualized or planned • No design work going into Simple Factory

Problem with Simple Factory • createPizza entirely dependent on 6 classes • Must change whenever these constructors modified 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); elseret = new Cheese(ret);}return ret; }

What if…

Or We Had…

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); elseret = new Cheese(ret);}return ret; } }

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); elseret = new Cheese(ret);}return ret; } abstract Pizza createPizzaType(); }

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

Factory Method UML • Clients call method in AbstractFactory • ConcreteFactory unknown by the clients

Factory Method Process • AbstractCreatordefines factory • Usually either an interface or abstract class • Does not instantiate any actual Products • Instances allocated byConcreteCreators • Each Product has own ConcreteCreator • Develop lines using many ConcreteCreators • DeepDishFactory & ThinCrustFactoryneeded • To create product lines for DeepDish & Cracker

Factory Method Intent • Interface & abstract class types always used for: • Variables • Fields • Parameters • Statics • Any & all required concreteness left for: • Factory methods • Code on critical path (& only if performance is critical)

Factory Method Intent • Interface & abstract class types always used for: • Variables • Fields • Parameters • Statics • Any & all required concreteness left for: • Factory methods • Code on critical path (& only if performance is critical) • Code passing “What would _______ code?” test

For Next Lecture • Lab #4 available on web/Angel • Due before next lab (Fri. 2/26) • Read pages 144 - 162 in the book • How can we easily enable skinnable applications? • Could I make even odder religious references?

Lecture 14: Programming & Religion