1. Design Patterns with C# (and Food!)
Matthew Jones

2. Who am I? Lead Software Developer for U-Haul International
Working on the MS/.NET stack for 10+ years.
Tech Blog:
Reading Blog:
SGOTI

3. What Are Design Patterns?

4. What Are Design Patterns?
Solutions to common problems
Targets of refactoring, not design
Powerful, flexible, reusable

5. Refactoring, Not Design
Patterns occur organically.
Tools, not goals.
Solve specific problems in predictable ways.
It’s OK to not use a pattern.

6. True Power of Design Patterns
Communication!

7. Pattern Types

8. Creational Patterns
Concerned with the creation of objects and instances.

9. Structural Patterns
Concerned with the overall design of the system and its constituent classes and objects.

10. Behavioral Patterns
Concerned with the assignment of responsibilities to objects and classes.

11. The GoF Patterns Bridge Interpreter Abstract Factory Composite
Strategy
Mediator
State
Proxy
Template Method
Chain of Responsibility
Prototype
Memento
Façade
Iterator
Decorator
Builder
Adapter
Observer
Flyweight
Command
Visitor
Factory Method
Singleton

12. Our Patterns Creational: Structural: Behavioral: Factory Method
Abstract Factory
Prototype
Structural:
Façade
Adapter
Composite
Behavioral:
Observer
Strategy
State

13. Factory Method

14. Factory Method - Purpose
Defines an interface for creating an object.
Specifies what to create, not how to do so.
How is left to subclasses.

15. Factory Method - Participants
Product: defines an interface for objects that the Factory Method will create.
ConcreteProduct: implements the Product interface.
Creator: declares the factory method and may specify a default implementation.
ConcreteCreator: overrides the factory method to return an instance of a ConcreteProduct.
All UML Diagrams created by Do Factory (

16. Factory Method Demo

17. Factory Method - Summary
Allows for families of objects to define their own methods and implementations while still being related.

18. Abstract Factory

19. Abstract Factory - Purpose
Defines interfaces for creating multiple families of objects.
Does not specify exactly how the object is created.

20. Abstract Factory- Participants
AbstractFactory: declares an interface for operations which will create AbstractProducts.
ConcreteFactory: implements the AbstractFactory interface and creates a ConcreteProduct.
AbstractProduct: declares an interface for a type of product.
Products: objects created by the ConcreteFactory.
Client: uses the abstract interfaces.

21. Abstract Factory Demo
Sandwich
Dessert
Concrete Products

22. Abstract Factory - Summary
Enables creation of different families of objects.
Factories are reusable.
Actual behaviors are defined by the concrete objects.

23. Prototype

24. Prototype - Purpose Create objects by cloning a prototypical instance.
Consumes less resources than creating new objects.

25. Abstract Factory- Participants
Prototype: declares an interface for cloning itself.
ConcretePrototype: objects implement the cloning operation.
Client: creates a new object by asking the Prototype to clone itself.

26. Prototype Demo

27. Protoype - Summary
Creates instances of objects by cloning a prototypical instance.
Used to create lots of similar objects.

28. Façade

29. Façade - Purpose
Consists of a simpler interface over a more complex interface (or group of interfaces).

30. Façade - Participants
Subsystems: classes, objects, or other components which need to be abstracted away from the client.
Façade: the layer of abstraction above the Subsystems. It knows which Subsystem to delegate work to.

31. Façade Demo – Kitchen Sections
Most kitchens are divided into areas.
Meats, apps, bar
Patrons don’t care who makes what.
Natural layer of abstraction: the server.

32. Façade - Summary
A thin layer of abstraction over a more complex system.

33. Adapter

34. Adapter - Purpose Makes two incompatible interfaces work together
Especially useful when one of the interfaces cannot be refactored

35. Adapter - Participants
Target: defines the domain- specific interface in use by the Client.
Client: collaborates with objects which conform to the Target interface.
Adaptee: the interface that needs adapting.
Adapter: adapts the Adaptee to the Target.
Note that the Adapter inherits from the Target.

36. Adapter Demo – Cook Temps

37. Adapter - Summary Makes two incompatible interfaces work together.
Co-opts an existing interface to do this.

38. Adapter vs Façade The Adapter pattern: The Façade pattern:
Uses an existing interface
Assumes that the two interfaces will work together.
The Façade pattern:
Creates a new interface
Assumes that the existing interfaces will NOT work together.

39. Composite

40. Composite - Purpose Represents part-whole hierarchies of objects
Each object in hierarchy inherits from common object
Or implements a common interface

41. Composite - Participants
Component: declares a common interface for objects in the hierarchy.
Implements common behavior and must have an interface for adding/removing its own children.
Leaves: nodes with no children.
Composite: defines behavior for nodes with children.
Client: manipulates objects in the composition through the Component interface.

42. Composite Demo – Sodas
This soda machine can dispense hundreds of flavors.
Interface is a drill down:
1. Pick a kind of drink
2. Pick a flavor
Not all flavors are offered for all drinks.

43. Composite Demo – Soda Tree

44. Composite - Summary
Treats all objects in a hierarchy as “the same”, since they inherit from common object.
Allows for “flattening” of the tree to acquire objects.

45. Observer

46. Observer - Purpose
Allows an object to notify other objects of its state change.
The “subject” must know who its “observers” are.

47. Observer - Participants
Subject: knows its Observers and provides an interface for attaching/detaching them.
ConcreteSubject: stores the state of interest to the Observers and sends automatic notifications.
Observer: defines an updating interface.
ConcreteObserver: maintains a reference to a ConcreteSubject and implements the Observer’s updating interface.

48. Observer Demo – Veggie Market
Say we have a vegetable market, where prices for veggies change daily.
We also have three restaurants who want to buy the veggies from the market when the price is low.
The restaurants need to be notified when the veggie prices change.

49. Observer - Summary
Subjects can notify their observers of their state change.
Observers receive notifications.
Subjects must maintain a reference to their Observers.

50. Strategy

51. Strategy - Purpose Encapsulates behavior as objects.
Allows for these behaviors to fire based on other inputs.
Behavior can be selected at runtime.

52. Strategy - Participants
Strategy: declares an interface which is supported by all ConcreteStrategies.
ConcreteStrategy: implements the Strategy interface.
Context: maintains a reference to a Strategy and uses that reference to call a ConcreteStrategy.

53. Strategy Demo – Cook Methods

54. Strategy - Summary Encapsulates behavior as objects.
Allows behavior to be selected at runtime.

55. State

56. State - Purpose Encapsulates behavior as objects.
Allows an object to change its own behavior at runtime.
Different from Strategy
Strategy picks behaviors based on external state.
State picks behaviors based on internal state.

57. State - Participants
State: defines an interface for encapsulating behavior.
ConcreteState: objects which each implement a behavior.
Context: defines an interface of interest to the clients and maintains a reference to an instance of a ConcreteState.

58. State Demo – Steak Doneness

59. State - Summary States are classes.
The object chooses which State class to use based on its own internal state.

60. Questions?

61. Thanks! Tech Blog: exceptionnotfound.net
Reading Blog: readaloudcorner.com
Daily Design Pattern: exceptionnotfound.net/introducing-the- daily-design-pattern/
Project Repository: