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

Who am I? Lead Software Developer for U-Haul International Working on the MS/.NET stack for 10+ years. Tech Blog: www.exceptionnotfound.net Reading Blog: www.readaloudcorner.com Twitter: @ExceptionFound SGOTI

What Are Design Patterns?

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

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

True Power of Design Patterns Communication!

Pattern Types

Creational Patterns Concerned with the creation of objects and instances.

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

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

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

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

Factory Method

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

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 (www.dofactory.com)

Factory Method Demo

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

Abstract Factory

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

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.

Abstract Factory Demo Sandwich Dessert Concrete Products

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

Prototype

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

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.

Prototype Demo

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

Façade

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

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.

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.

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

Adapter

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

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.

Adapter Demo – Cook Temps

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

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.

Composite

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

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.

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.

Composite Demo – Soda Tree

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.

Observer

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

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.

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.

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

Strategy

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

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.

Strategy Demo – Cook Methods

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

State

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.

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.

State Demo – Steak Doneness

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

Questions?

Thanks! Tech Blog: exceptionnotfound.net Reading Blog: readaloudcorner.com Daily Design Pattern: exceptionnotfound.net/introducing-the- daily-design-pattern/ Project Repository: https://github.com/exceptionnotfound/DesignPatterns Twitter: @ExceptionFound