Patterns are everywhere
This great comic is from False Knees and it illustrates that you can find patterns everywhere, you can also check out this National Graphic article. Your code base is no different.
The objective of this article is to understand or refresh the memory of the different patterns and then jump into Dependency Injection to do something cool.
Resources
You can find all of the code in this repository on my Github.
If you are kind of new or not sure what's all this about I recommend you read my previous blog post: Software Engineering OOP principles and good practices to avoid spaghetti code.
Additionally, I highly recommend the site Refactor Guru to learn about design patterns and refactoring.
As well as Christopher Okhravi's Youtube Channel for more in-depth videos and examples, he's a great teacher.
Tip
I recommend exploring all the resources above to have a better understanding of each pattern as my intention is to provide and simplify examples. Wikipedia is another great resource but it might be a bit too difficult for beginners.
Strategy
The strategy pattern allows you to select an algorithm at run time. The name is "strategy" because given a certain context you can select a strategy appropriate for that context.
This is directly related to one of the SOLID principles, the open-closed principle that states software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.
Let's look at an example with TypeScript, and if you are using any other language the most important part is you understand how the classes and interfaces work together.
interface Strategy {
execute(str: string): string
}
class upperCaseStrategy implements Strategy {
public execute(str: string): string {
return str.toUpperCase()
}
}
class lowerCaseStrategy implements Strategy {
public execute(str: string): string {
return str.toLowerCase()
}
}
class Context {
private strategy: Strategy
constructor(strategy: Strategy) {
this.strategy = strategy
}
public setStrategy(strategy: Strategy) {
this.strategy = strategy
}
public executeStrategy(str: string): string{
return this.strategy.execute(str)
}
}
const randomString = 'rAnDoM sTrInG'
console.log('inittial string:', randomString)
const context = new Context(new upperCaseStrategy())
const upperCaseString = context.executeStrategy(randomString)
console.log('upper case:', upperCaseString)
context.setStrategy(new lowerCaseStrategy())
const lowerCaseString = context.executeStrategy(upperCaseString)
console.log('lower case:', lowerCaseString)
In this example you can see how we will be able to use the same Context class throughout our entire program but by changing strategies we will be able to get different results when we call the executeStrategy method.
If you want more complex examples Refactoring Guru has a cache implementation in Go and a payment method in Java.
Dependency Injection vs Strategy
If you are somehow familiar with DI and not sure why the strategy pattern is used, I'd recommend reading this Stack Overflow Answer.
Observer
The observer pattern relies on one principle: the observable (which often is called subject or event manager) needs to notify/update the observers (which can be called subscriber) it contains about an event.
The most common case would be a notification of some kind, you want to notify your users (or a specific set of users) about something that has happened so you take the observers and push their update method.
Note that for the observers to be notified they need to be somehow connected to the observable and the observable also needs to have a way to call the notify/update methods of the observables.
Let's look at the code, but keep in mind that I'm using the words observable, subject and event manager/dispatcher interchangeably. The same goes for observer and subscriber.
interface Observable {
add(observer: Observer): void
remove(observer: Observer): void
notify(): void
}
interface Observer {
name: string
update(observable: Observable): void
}
class Subject implements Observable {
name: string
constructor(name: string) {
this.name = name
}
private observersMap: Map<Observer['name'], Observer> = new Map<Observer['name'], Observer>
public add(observer: Observer): void {
this.observersMap.set(observer.name, observer)
console.log(`added observer ${observer.name} to ${this.name}`)
}
public remove(observer: Observer): void {
this.observersMap.delete(observer.name)
console.log(`removed observer ${observer.name} to ${this.name}`)
}
public notify(): void {
this.observersMap.forEach((v,k,m) => v.update(this))
}
public getName(): string {
return this.name
}
public changeName(name: string): void {
console.log(`changing name from ${this.name} to ${name}..`)
this.name = name
console.log(`notifications being sent..`)
this.notify()
}
}
class webObserver implements Observer {
name: string
constructor(name: string) {
this.name = name
}
update(observable: Subject): void {
console.log(`${this.name} notification from ${observable.getName()}`)
}
}
class phoneObserver implements Observer {
name: string
constructor(name: string) {
this.name = name
}
update(observable: Subject): void {
console.log(`${this.name} notification from ${observable.getName()}`)
}
}
const subject = new Subject('THANOS SERVICE')
const webObs = new webObserver('WEB')
const phoneObs = new phoneObserver('PHONE')
subject.add(webObs)
subject.add(phoneObs)
subject.notify()
subject.changeName('IRONMAN')
This is the output:
If you want more examples feel free to check Refactoring Guru, here's Go and Java.
Observer vs Pub/Sub
You might have noticed that the observer pattern could end up being too tightly coupled and it's very similar to another architecture: pub/sub.
Pub/Sub is a bit different and adds complexity, however it's great if you decide to work with events as it provides a separate channel for subscribers.
Singleton
If you want to ensure there's only one instance of the class then use the singleton pattern. Although some people might argue against it this pattern is widely used, especially with database connections.
The beauty of this design is its use of the private initializer.
class Singleton {
private static singleton: Singleton
private constructor() {
console.log('starting singleton..')
}
public static getSingleton(): Singleton {
console.log('getting singleton..')
if(!Singleton.singleton) {
console.log('no singleton available')
Singleton.singleton = new Singleton()
}
return Singleton.singleton
}
}
function mainProgram() {
const singleton1 = Singleton.getSingleton()
const singleton2 = Singleton.getSingleton()
if(singleton1 === singleton2) {
console.log('same instance')
}
}
mainProgram()
This is the output:
As always Refactoring Guru has examples in Java and Go as well.
Factory
As you can see in the UML diagram the whole point of the factory pattern is to have a specific place (interface of the factory) where you can create the needed objects. The factory is called "creator" and the objects created are called "products".
Basically what we are doing is encapsulating the business logic (a particular way of constructing objects). The principle is very simple but you can make it as complex as you want, the idea is to always have a factory method available that you can move around your codebase and get the concrete objects you want or need.
I really like this definition from Refactoring Guru:
Factory Method is a creational design pattern that provides an interface for creating objects in a superclass, but allows subclasses to alter the type of objects that will be created.
Let's look at a code example with TypeScript:
interface Pizza {
name: string
getName(): string
cookingTime(): void
eat(): void
}
class NewYorkPizza implements Pizza {
name: string
constructor(name: string) {
this.name = name
}
getName(): string {
return this.name
}
cookingTime(): void{
console.log('15min')
}
eat(): void {
console.log('eating NY pizza')
}
}
class ChicagoPizza implements Pizza {
name: string
constructor(name: string) {
this.name = name
}
getName(): string {
return this.name
}
cookingTime(): void {
console.log('30min')
}
eat(): void {
console.log('eating Chicago pizza')
}
}
interface PizzaFactory {
makePizza(pizza: Pizza): Pizza
}
class NewYorkRestaurant implements PizzaFactory {
makePizza(): Pizza {
return new NewYorkPizza('best NY pizza')
}
}
class ChicagoRestaurant implements PizzaFactory {
makePizza(): Pizza {
return new ChicagoPizza('best Chicago pizza')
}
}
const newYorkRestaurant: NewYorkRestaurant = new NewYorkRestaurant()
const chicagoRestaurant: ChicagoRestaurant = new ChicagoRestaurant()
const myNewYorkPizza = newYorkRestaurant.makePizza()
const myChicagoPizza = chicagoRestaurant.makePizza()
const newYorkPizzaName = myNewYorkPizza.getName()
console.log(`NY pizza name is: ${newYorkPizzaName}`)
myNewYorkPizza.cookingTime()
const chicagoPizzaName = myChicagoPizza.getName()
console.log(`NY pizza name is: ${chicagoPizzaName}`)
myChicagoPizza.cookingTime()
This is the output:
Check out additional examples from RG: Java and Go.
Abstract Factory
The Factory method is usually used, or well, it evolves into an Abstract Factory. As the name says, what you do is abstract the factory so you can make more concrete factories that mix different implementations of the concrete products.
This UML from Wikipedia sums it up fairly well:
Refactoring Guru uses a GUI example and I think is the best one for this pattern, so check it out:
They also have pseudocode that illustrates everything going on. This Python example from Wikipedia is also pretty good.
Dependency Injection
DI is one of those concepts that can be either too easy to understand or too hard, and by this I mean even people who use it constantly might not be able to fully explain the cycle of what's going on or how it works.
My intention is to give you a general understanding so you could dive further in, or at least be able to use DI in your projects.
The picture above is from this article. You don't have to read it, I just want to point out there's a lot going on. Additionally for a more in depth post on Inversion of Control I recommend this article from Martin Fowler (if you don't know who he is then you should definitely check out his blog).
Dependency Injection relies on the Inversion of Control principle.
IoC
As always one of the main problems when writing software is tight coupling, in OOP you get classes entangled with each other which makes it impossible to extend or modify. This issue is mainly because the Open-Closed Principle isn't followed.
We apply Inversion of Control to loosen and decouple our classes. Invert the control of dependencies. Instead of our current class controlling the creation of a new class we want to have something in between, a layer of abstraction that will have that control instead.
IoC isn't only applied to classes but I want to make this as simple as possible.
You can think about IoC as removing the dependency for further extension.
The picture above is from this article and has some examples.
DI Example
The theory is the same as with IoC, we want to avoid hard-coded dependencies so we can maintain our code in the future. Interfaces and design patterns exist, let's use them.
Knowing all of the above let's think about how to implement Dependency Injection: the main thing we have to do is to relinquish the control of creating an object we need somewhere else. We are still going to use the object of course so we need to store it, but let's not worry about how it gets made.
The best examples I could find are from Digital Ocean (Java) and Android (Kotlin, Java) so feel free to dig in, I liked the example from Android so I'm going to simplify it with TypeScript.
Constructor Injection: You pass the dependencies of a class to its constructor.
class Engine {
ignite(): void {
console.log('vroom vroom')
}
}
class Car {
engine: Engine
constructor(engine: Engine) {
this.engine = engine
}
start(): void {
this.engine.ignite()
}
}
const engine = new Engine()
const car = new Car(engine)
car.start()
You should get a 'vroom vroom' when you run it!
Tekbeans
If you made it all the way here congratulations!
I've started working on a TS package called tekbeans, it's on npm and of course you can check the source code on Github. It's on very early stages, however if you want to dig deeper into IoC and DI with TS then feel free to play with it. The package will be heavily inspired on Spring as it's the most famous framework with DI that uses explicit beans I believe.
Fin
As a reminder, you can find the code to all examples on my Github in the patterns repository, I will probably keep adding interesting stuff there.
You can also follow me here or reach out on Twitter or maybe even Mastodon.
It's 4 AM right now as I'm finishing this article, so if it has helped you in any way let me know, insults are welcome as well since this is the internet.
