Design Patterns


Uncategorized

Updated Mar 21st, 2022

Overview

Check out refactoring.guru, cool site all about design patterns.

From the Web

Jack Herrington on Traversy Media Published 9/14/2020

Stop thinking of career progression as just a Junior – Senior – Lead – Architect – Principal (x-axis) and start thinking about moving from being a consumer of frameworks (Like React or Vue) versus creators of frameworks (y-axis). You can move up the y-axis by building up from language proficiency (conditionals, looping, etc.), data structures/algorithms, and then finally into design patterns.

Design patterns are ways of designing solid architectures that are reusable and extensible and are industry standards.

There is a legendary book, “Design Patterns, Elements of Reusable Object-Oriented Software” that is written in C++ but concepts work in any language or environment. Written by the gang of four. Break Design Patterns into three categories: Creational, Structural, Behavioral. There are twenty three in the book.

Here are 5 design patterns:

  1. Singleton
  2. Facade (Building)
  3. Bridge (Modular)
  4. Strategy
  5. Observer Pattern aka PubSub (Author’s favorite)

Singleton

Only one instance

Facade

The front of the building hides all the pipes and plumbing. Think about a framework compiler. Can have leaky extraction or over-specific

Bridge

Camera example that is two pieces, body and interchangeable lens. API is interface and software is the lens. Con is when you use too much. Can bring in it later.

Strategy

Cleans up code by creating an infrastructure layer. Have decent default strategies.

Observer aka PubSub

Allows for loose coupling between publisher and subscribers. Keep the systems localized.

From The Tech Lead

The problem design patterns try to solve: code gets messy, especially in larger projects, everyone has their own coding patterns and over time nothing makes sense. Different naming schemes, data flow going all over the place, dependencies all over the place, classes that are known as God classes, do everything, also know as kitchen sink mega classes (thousands of lines of code). not clear where responsibility begins and ends.

Design patterns can help you manage the complexity. More so than any algorithm. Design patterns are good to bring up in job interviews and keep speak more broadly about their system. What are the dependencies between the modules in your program. Good to imagine if you expand and you had 100s of designer how would you divide it up so everyone isn’t trampling on each other and creating merge conflicts. How to break up your project into individual components and have key dependencies.

What are the nouns (classes) inside your program and what is the data flow between them. Can’t have a bunch of singletons and data flying all over the place.

Simplicity and one-way data flow. Limit the types of objects you have in your system, maybe have controllers, views (UI), and data objects (Business Logic). And that’s it. If you are starting to introduce like managers, coordinators, helpers, executor, handlers, providers. becomes different to understand differences. Keep the data flow in one direction to keep it simple. Views should not contain business logic. If you find a bug you can narrow it down more quickly.

Single Responsibility: every class or even every method has single responsibility and it doesn’t do more than that. Keeps reasoning what is doing what very simple. Break down into more isolated components.

When looking at overall structure, follow the ownership graph (which object own which other object). Data should go from the parent and the child. Two parents modify child could easily give rise to conflict, bugs, more complication, memory leaks, etc.

Singletons are great because they exist in their own little area, don’t have a lot of dependencies. Works great for many teams, as they can each create their own Singletons. One problem is they can easily introduce two way data flow in your program. Can make data flow a nightmare as they grow in number, soon tracing events from one singleton to the next singleton to the next and it becomes difficult to understand how the whole system is functioning.

Communication Pattern: Singletons cannot communicate with each other directly but need to issue notifications and other Singletons can listen to these notifications. Helps data flow downwards from central notification hub.

Publish Subscribe Pattern: A variation on above, have some Singletons have a publish subscribe interface. Single broadcasting object and many other listener objects awaiting events on that. This is the _ describe interface and one of his favorites. Very versatile pattern. Encourages one-way data flow.

Delicate Pattern: Variation on pub-sub pattern. Common in iOS programming. An object can give callbacks to another explaining what it is doing. Like the pub-sub-observer pattern but there is typically only one single delegate.

Chain of Responsibility Pattern: Type of communication design pattern. See in hierarchical tree structure. Communicate events upwards. Child issues an event and parent tries to handle and if it can’t then keeps bubbling up to parent, to gran-parent to great-grand-parent until the event can be handled or it gets to the top. Two way data flow. Event bubbling is anti-pattern you can choose to allow based on convenience.

Object Oriented Programming is a concept pushed quite a bit in school, especially inheritance, the reality is inheritance is a pretty poor design structure as it can get pretty messy pretty quickly. If you don’t do it right you can have a sub class communicate to super class, to super super class, and two-way data flow. Then this inheritance structure become deeply tied to one another and becomes impossible to refactor things. Can’t refactor super class because super super class or sub class breaks. These inheritance structures may make some sense but oftentimes you want to take a look at the containment pattern instead.

Containment Pattern: Have a class that contain other little objects and a controller that can delegate behavior to mix and match things, without getting the intertangled hierarchy structure of polymorphism and inheritance structure you may see with object oriented programming

Lazy Initialization Pattern: Don’t create objects until you need them. Great way to increase startup performance time.

Adapter Pattern: Have many different types of objects with different methods and APIs and using an adapter you can have them all match a certain set of APIs and interfaces such that you can perform a common set of operations on them. Can be implemented with protocols or wrapper classes.

“Factory Builder Classes” are another one that will be seen quite often. Like a catalog that indicates what type of classes will be instantiated and when. Especially useful when needing to create a header genius group of different components.

From Mosh

Design Patterns in Plain English – Published 1/6/2020

Reusable and extensible object oriented software. The example in this video uses Java.

Can express idea with pattern.

From Tim Corey

Frustrating that beginners don’t need to know design patterns right away. Learn how to write code. Does it do the job ? Yes. Great. Can it be better? Of Course. Start with DRY (don’t repeat yourself) principle before moving into design patterns. From DRY principle go to SOLID principles. SOLID principles are good for teams but still helpful.