↓Skip to main content
  1. Refs/

Design Patterns

··3 mins
Table of Contents

Go To References #

Videos #

  • 5 Design Patterns Every Engineer Should Know | Jack Herrington via Traversy Media - Explains importance of design patterns in moving from a Framework Consumer to a Framework Creator:
    • Singleton - Only have one instance which is always available and ready for use (e.g. a DB driver)
    • Facade - Simple/elegant interface which hides all the ugly internals from the user; watch out for making it too simple or too specific to a single use case
    • Bridge/Adapter - Create interfaces to make it possible to switch out implementation (e.g. DSLR cameras and various lenses); watch out for overusing the pattern everywhere. can start out with a single implementation and then as it is being used and you see specific areas that warrant modularity, implement it there.
    • Strategy - splits up larger methods into smaller configurable strategies focused on doing a single thing, which allows further reuse; make sure that there are good default strategies;
    • Observer (Pub/Sub) - Event based communication from publishers/providers to subscribers/consumers; do not over use as it may become hard to debug and may cause event explosion; Maybe have multiple event buses, or keep the amount of messages limited;
  • 10 Design Patterns Explained in 10 Minutes | Fireship - Overview of 10 common patterns across three overarching buckets:
    • Creational: how objects are created
      • Singleton - Object can only be created once (e.g. Settings)
      • Prototype - Clone an instance of an object to extend it
      • Builder - Create object with chained methods instead of with long constructor
      • Factory - Separate method to create objects based on current context; instead of client determining context and creating directly, that logic is now handled by the factory - the caller just needs to pass the context
    • Structural: how objects relate to each other
      • Facade - Simplified API to hide low-level details; allows basic interactions with the low-level, without getting into the weeds.
      • Proxy - Substitute target object with a proxy object (e.g. Vue’s reactivity system). Useful to not have to copy or store large objects (like a Database)
    • Behavioral: how objects communicate with each other
      • Iterator - Traverse through collection of objects (e.g. for, range). Can allow stepping through the collection with the next function.
      • Observer - Many-to-one relationship between subscribers and publisher (e.g. Radio Tower & Receivers)
      • Mediator - Middleman / broker / middleware which simplifies communication. Instead of many-to-many, it turns into many-to-one-to-many (e.g. Air traffic controller sitting between runways and airplanes)
      • State - Objects behave differently based on a finite number of states (e.g. State Machine). Related to the Open/Closed Principle in SOLID
  • Why COMPOSITION is better than INHERITANCE-detailed Python example | ArjanCodes – Blind overuse of inheritance does not actually reduce code duplication and can result in an explosion of subclasses for every possible variant. Composition solves for code de-duplication and gives you flexibility in how you construct objects. Very useful to combine composition with the Factory pattern.
  • The Factory Pattern in Python // Separate creation from use | ArjanCodes – Allows you to separate creation of objects from where you are using them. Very useful to combine with Dependency Injection / Dependency Inversion.
↑