TDDB84: Lecture 4 Abstract Factory, Dependency Injection, Composite - - PowerPoint PPT Presentation

▶
tddb84 lecture 4
SMART_READER_LITE
LIVE PREVIEW

TDDB84: Lecture 4 Abstract Factory, Dependency Injection, Composite - - PowerPoint PPT Presentation

Mar 05, 2023 468 likes •1.23k views

TDDB84: Lecture 4 Abstract Factory, Dependency Injection, Composite Abstract factory Ingredients Pizza Store Clients Fresh Clam NY Mozzarella Cheese Thin Crust Dough I Want a Cheese Pizza Chicago Frozen Clam Parmesan Cheese Thick

slide-1
SLIDE 1

TDDB84: Lecture 4

Abstract Factory, Dependency Injection, Composite

slide-2
SLIDE 2

Abstract factory

slide-3
SLIDE 3

NY Chicago

Fresh Clam Mozzarella Cheese Thin Crust Dough Frozen Clam Parmesan Cheese Thick Crust Dough

Ingredients Pizza Store Clients

I Want a Cheese Pizza

slide-4
SLIDE 4

NY Chicago

Fresh Clam Mozzarella Cheese Thin Crust Dough Frozen Clam Parmesan Cheese Thick Crust Dough

Ingredients Pizza Store Clients

I Want a Cheese Pizza

slide-5
SLIDE 5

NY Chicago

Fresh Clam Mozzarella Cheese Thin Crust Dough Frozen Clam Parmesan Cheese Thick Crust Dough

Ingredients Pizza Store Clients

I Want a Cheese Pizza

slide-6
SLIDE 6
slide-7
SLIDE 7
slide-8
SLIDE 8
slide-9
SLIDE 9
slide-10
SLIDE 10
slide-11
SLIDE 11
slide-12
SLIDE 12

Abstract Factory

slide-13
SLIDE 13

Abstract Factory Concrete Factory

slide-14
SLIDE 14

Abstract Products Abstract Factory Concrete Factory

slide-15
SLIDE 15
slide-16
SLIDE 16

Clients

slide-17
SLIDE 17

Abstract factory: consequences

slide-18
SLIDE 18

Abstract factory: consequences

+Isolates clients from

concrete dependencies

slide-19
SLIDE 19

Abstract factory: consequences

+Isolates clients from

concrete dependencies

+Makes interchanging

families of products easier

slide-20
SLIDE 20
slide-21
SLIDE 21

Strategy

slide-22
SLIDE 22

Strategy

  • When related classes only

differ in behavior

  • You need different variants
  • f an algorithm
  • An algorithm uses data the

clients don’t need to know

  • A class uses conditionals

for selecting behavior

slide-23
SLIDE 23

Strategy

  • When related classes only

differ in behavior

  • You need different variants
  • f an algorithm
  • An algorithm uses data the

clients don’t need to know

  • A class uses conditionals

for selecting behavior

Abstract Factory

  • A system should be

independent of how its products are created

  • A system should be

configured with one of multiple families of products

  • You want to provide a class

library of products, and only expose their interfaces

slide-24
SLIDE 24

Strategy

  • When related classes only

differ in behavior

  • You need different variants
  • f an algorithm
  • An algorithm uses data the

clients don’t need to know

  • A class uses conditionals

for selecting behavior

Abstract Factory

  • A system should be

independent of how its products are created

  • A system should be

configured with one of multiple families of products

  • You want to provide a class

library of products, and only expose their interfaces

Behavioral

slide-25
SLIDE 25

Strategy

  • When related classes only

differ in behavior

  • You need different variants
  • f an algorithm
  • An algorithm uses data the

clients don’t need to know

  • A class uses conditionals

for selecting behavior

Abstract Factory

  • A system should be

independent of how its products are created

  • A system should be

configured with one of multiple families of products

  • You want to provide a class

library of products, and only expose their interfaces

Behavioral Creational

slide-26
SLIDE 26

Design principles

  • Encapsulate what varies
  • Program to an interface, not to an

implementation

  • Favor composition over inheritance
  • Classes should be open for extension but

closed for modification

  • Don’t call us, we’ll call you
slide-27
SLIDE 27

Design principles

  • Encapsulate what varies
  • Program to an interface, not to an

implementation

  • Favor composition over inheritance
  • Classes should be open for extension but

closed for modification

  • Don’t call us, we’ll call you
slide-28
SLIDE 28

Design principles

  • Encapsulate what varies
  • Program to an interface, not to an

implementation

  • Favor composition over inheritance
  • Classes should be open for extension but

closed for modification

  • Don’t call us, we’ll call you
slide-29
SLIDE 29

Dependency Injection

slide-30
SLIDE 30

Distinguished by namespaces in C#

  • cheese

ICheesePizza <<ICheese> > MozzarellaCheese ParmesanCheese <<IClam>> FreshClam FrozenClam

  • cheese
  • clam

IClamPizza FancyClamPizza StandardCheesePizza NYStyle ChicagoStyle

slide-31
SLIDE 31

DI: How?

slide-32
SLIDE 32
  • 1. Declare dependencies as constructor

arguments of interface types

DI: How?

slide-33
SLIDE 33
  • 1. Declare dependencies as constructor

arguments of interface types

  • 2. Register classes (components) in an

Inversion-of-Control Container

DI: How?

slide-34
SLIDE 34
  • 1. Declare dependencies as constructor

arguments of interface types

  • 2. Register classes (components) in an

Inversion-of-Control Container

  • 3. Resolve the top-level object from an

interface through the Container

DI: How?

slide-35
SLIDE 35
  • 1. Dependencies

namespace DITest {

  • public class FancyClamPizza: IClamPizza
  • {
  • private IClam clam;
  • private ICheese cheese;
  • public FancyClamPizza (IClam clam, ICheese cheese)
  • {
  • this.clam = clam;
  • this.cheese = cheese;
  • }
  • public String ClamType() {
  • return String.Format("fancy {0}",clam);
  • }
  • public String Describe() {
  • return String.Format("fancy clam pizza with {0} and {1}",ClamType(), cheese);
  • }
  • }

}

slide-36
SLIDE 36
  • 2. Registration

namespace DITest {

  • public class IoCInstaller: IWindsorInstaller
  • {
  • public void Install(IWindsorContainer container, IConfigurationStore store)
  • {
  • container.Register(Classes
  • .FromThisAssembly()
  • .InNamespace("DITest.NYStyle")
  • .WithServiceAllInterfaces());
  • container.Register (Classes
  • .FromThisAssembly()
  • .AllowMultipleMatches()
  • .InSameNamespaceAs<IoCInstaller>()
  • .WithServiceAllInterfaces());
  • }
  • }

}

slide-37
SLIDE 37
  • 2. Registration

namespace DITest {

  • public class IoCInstaller: IWindsorInstaller
  • {
  • public void Install(IWindsorContainer container, IConfigurationStore store)
  • {
  • container.Register(Classes
  • .FromThisAssembly()
  • .InNamespace("DITest.NYStyle")
  • .WithServiceAllInterfaces());
  • container.Register (Classes
  • .FromThisAssembly()
  • .AllowMultipleMatches()
  • .InSameNamespaceAs<IoCInstaller>()
  • .WithServiceAllInterfaces());
  • }
  • }

}

Castle Windsor, http://www.castleproject.org

slide-38
SLIDE 38
  • 3. Resolution
  • var container = new WindsorContainer();
  • // adds and configures all components using WindsorInstallers from executing assembly
  • container.Install(FromAssembly.This());
  • // instantiate and configure root component and all its dependencies and their dependencies and...
  • var p = container.Resolve<ICheesePizza>();
  • Console.WriteLine (p.Describe ());
slide-39
SLIDE 39

Demo

slide-40
SLIDE 40

Design principles

  • Encapsulate what varies
  • Program to an interface, not to an

implementation

  • Favor composition over inheritance
  • Classes should be open for extension but

closed for modification

  • Don’t call us, we’ll call you
  • Depend on abstractions, do not depend on

concrete classes

slide-41
SLIDE 41

Composite

slide-42
SLIDE 42
slide-43
SLIDE 43

Ok, now we’re done with menus, coffees and pizzas. Right?

slide-44
SLIDE 44

Ok, now we’re done with menus, coffees and pizzas. Right? Right?

slide-45
SLIDE 45

Ok, now we’re done with menus, coffees and pizzas. Right? Right? No.

slide-46
SLIDE 46

We need a desert menu!

Ok, now we’re done with menus, coffees and pizzas. Right? Right? No.

slide-47
SLIDE 47

We need a desert menu! We need a coffee menu!

Ok, now we’re done with menus, coffees and pizzas. Right? Right? No.

slide-48
SLIDE 48
slide-49
SLIDE 49

Waiter

slide-50
SLIDE 50

Waiter

printMenu()

slide-51
SLIDE 51

Coffee menu Dark roast Coffee Tea Espresso

Waiter

printMenu()

slide-52
SLIDE 52

Breakfast menu Coffee menu Ham & eggs Spam & eggs Eggs & spam Spam, spam & eggs Coffee menu Dark roast Coffee Tea Espresso

Waiter

printMenu()

slide-53
SLIDE 53

Breakfast menu Coffee menu Ham & eggs Spam & eggs Eggs & spam Spam, spam & eggs Coffee menu Dark roast Coffee Tea Espresso Pizza menu Coffee menu Clam Pizza Cheese Pizza

Waiter

printMenu()

slide-54
SLIDE 54

Breakfast menu Coffee menu Ham & eggs Spam & eggs Eggs & spam Spam, spam & eggs Coffee menu Dark roast Coffee Tea Espresso Pizza menu Coffee menu Clam Pizza Cheese Pizza Diner menu

Waiter

printMenu()

slide-55
SLIDE 55

Breakfast menu Coffee menu Ham & eggs Spam & eggs Eggs & spam Spam, spam & eggs Coffee menu Dark roast Coffee Tea Espresso Pizza menu Coffee menu Clam Pizza Cheese Pizza Diner menu

Waiter

printMenu() print()

slide-56
SLIDE 56

Breakfast menu Coffee menu Ham & eggs Spam & eggs Eggs & spam Spam, spam & eggs Coffee menu Dark roast Coffee Tea Espresso Pizza menu Coffee menu Clam Pizza Cheese Pizza Diner menu

Waiter

printMenu() print() print()

slide-57
SLIDE 57

Breakfast menu Coffee menu Ham & eggs Spam & eggs Eggs & spam Spam, spam & eggs Coffee menu Dark roast Coffee Tea Espresso Pizza menu Coffee menu Clam Pizza Cheese Pizza Diner menu

Waiter

printMenu() print() print() print()

slide-58
SLIDE 58

Breakfast menu Coffee menu Ham & eggs Spam & eggs Eggs & spam Spam, spam & eggs Coffee menu Dark roast Coffee Tea Espresso Pizza menu Coffee menu Clam Pizza Cheese Pizza Diner menu

Waiter

printMenu() print() print() print() print()

slide-59
SLIDE 59
slide-60
SLIDE 60
slide-61
SLIDE 61

Client

slide-62
SLIDE 62

Client Component

slide-63
SLIDE 63

Client Component Composite

slide-64
SLIDE 64

Client Component Composite Leaf

slide-65
SLIDE 65

Composite: consequences

slide-66
SLIDE 66

Composite: consequences

+Allow us to treat

composite objects and individual objects uniformly

slide-67
SLIDE 67

Composite: consequences

+Allow us to treat

composite objects and individual objects uniformly

+Allows arbitrarily

complex trees

slide-68
SLIDE 68

Composite: consequences

  • Creates composite

classes that violate the principle of a single responsibility

+Allow us to treat

composite objects and individual objects uniformly

+Allows arbitrarily

complex trees

slide-69
SLIDE 69

Composite: consequences

  • Creates composite

classes that violate the principle of a single responsibility

  • The composite cannot

rely on components to implement all methods

+Allow us to treat

composite objects and individual objects uniformly

+Allows arbitrarily

complex trees

slide-70
SLIDE 70

Exam question

1. What are the relationships between the Strategy and Flyweight patterns? a) They both concern decoupling objects from their dependencies b) Using a Flyweight pattern may also require the Strategy pattern c) Using the Strategy pattern may also result in using the Flyweight pattern d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern e) You often implement the Flyweight pattern by using the Strategy pattern for object creation f) The Flyweight pattern is a simplified form of the Strategy pattern

slide-71
SLIDE 71

Lecture 4 Lecture 5

Proxy Singleton

slide-72
SLIDE 72

Lecture 4 Lecture 5

Proxy Singleton

slide-73
SLIDE 73

Lecture 4 Lecture 5

Proxy Dynamic proxies in C# & Java Singleton

slide-74
SLIDE 74

Lecture 4 Lecture 5

Proxy Dynamic proxies in C# & Java Singleton Classes ARE objects, and each object can have a class (in Ruby)

slide-75
SLIDE 75

Lecture 4 Lecture 5

Proxy Dynamic proxies in C# & Java Singleton Classes ARE objects, and each object can have a class (in Ruby)

Yes, it may be on the exam