Patterns

That Conference 2018 – Design Patterns: Not Just for Architects

Posted by

0

That Conference 2018, Kalahari Resort, Lake Delton, WI
Design Patterns: Not Just for Architects – Jeremy Clark

Day 2, 7 Aug 2018  1:00 PM

Disclaimer: This post contains my own thoughts and notes based on attending That Conference 2018 presentations. Some content maps directly to what was originally presented. Other content is paraphrased or represents my own thoughts and opinions and should not be construed as reflecting the opinion of the speakers.

Executive Summary

  • There exist lots of design patterns that have been defined
  • We already use many of these without realizing it
  • Worth learning them–helps in communication
  • Examples of several patterns in C#

 

Goal: We’re already using design patterns, so worth putting a name on them

 

What are Design Patterns?

  • (Christopher Alexander quote)
  • Describes solution in a way that you can use it over and over again

 

Gang of Four book (GoF)

  • Gamma, Helm, Johnson, Vlissides
  • “Serious developer” needs to have this
  • Still relevant?  Yes
  • Examples in C++ and Smalltalk

 

Anatomy of a Design Pattern

  • Pattern Name
    • Unique way of referring to pattern
  • Problem
    • Problem that occurs over and over again
  • Solution
    • “Core” of the solution
    • Example implementations are not solutions
  • Consequences
    • Pros and cons
    • Things to watch out for

 

GoF Patterns

  • 23 different patterns
  • Categories
    • Creational
    • Structural
    • Behavioral
  • Book is a bit academic
    • Go through it at some point in your career
    • “You’re not ready for it yet”

 

Good starting point

  • Head First Design Patterns – Freeman, Freeman
  • Covers 12 of the GoF patterns
    • Same descriptions
    • Just explains it in a more approachable way
  • Examples in Java
    • But pretty general, so ok
    • Online, translations into various programming languages

 

Why Should We Care?

  • These are well-described solutions
  • Shared vocabulary
    • Easier to talk with other devs
  • Concise language
    • Quicker/shorter to just mention the pattern, rather than describing it in detail
  • Think in design rather than implementation
  • Encourage other developers to learn patterns

 

Observer pattern

  • When object changes state, dependent objects notified automatically
  • Publish-subscribe relationship

 

Real World Observer

  • Twitter – someone tweets, subscribers are notified

 

Implementation of Observer (C#)

  • Event handlers on button
  • This is ubiquitous in C# and in frameworks
  • Problem => Pattern => implementation of the pattern
    • E.g. pubsub => Observer pattern => event handlers
  • Prism, event aggregator
    • Publisher, subscribers don’t know about each other
  • .NET 4.0 – IObserver<T>
  • Consequences
    • I don’t know how many times I’ll be notified
    • Don’t know how frequently I’ll be notified
    • Don’t know if we’ll ever be notified

 

Iterator Pattern

  • Access elements of object sequentially without knowing about implementation of the thing
  • Get next item, stops at end
  • Real-world: Channel up button on TV Remote
  • In C#, foreach loop uses the iterator

 

Implementation of Iterator (C#)

  • Get List<T>, case to IEnumerable<T>
  • IEnumerable<T> says that object supports get next element (foreach)
  • All collections in .NET implement IEnumerable<T>
  • Nice that this is built into .NET (C#)

 

Facade Pattern

  • Unified interface for a set of interfaces in a sub-system
  • Higher-level interface makes things easier to use
  • Wrap complex stuff in simpler API

 

Real World Facade

  • Universal remote control wrapping access to multiple devices

 

Facade Implementation

  • foreach loop is also an example of facade
  • GetEnumerator
  • while (enumerator.MoveNext()) … do something with enumerator.Current()
  • foreach is a nice wrapper around this
  • Consequences
    • We might lose functionality that lower level stuff has
    • E.g. foreach doesn’t give access to Reset() method

 

Chain of Responsibility

  • Avoid coupling sender to receiver
  • Giving more than one object a chance to handle the request
  • Pass request along thru children until somebody handles it

 

Real-world example

  • Tech Support – first line, person asks questions
    • If not, passes to next person, more detailed look at your question

 

Chain of Responsibility Implementation

  • Throw exception
  • Catch certain types of exceptions at certain levels in call stack
  • If not caught at one level, it propagates up to the next level
  • Consequences
    • What is nobody handles the message?

 

Proxy Pattern

  • Provide surrogate for another object to control access to it
  • Example: Power of Attorney
    • One person makes another their proxy
  • Surrogate vs. placeholder
    • Placeholder–thumbnail or icon that only loads something when you click it
    • Good idea in mobile apps–delay download of some stuff, in case you have slow connection

 

Proxy Pattern Implementation

  • Web API service, controller with Get method
  • Get collection, return via service
  • Can create proxy service class that can call the service
    • HTTP clients
  • Use the proxy in the same way that you’d treat the original class
  • Consequences
    • Hides what’s really going on with the underlying object

 

A Million Implementations

  • Use over and over