There are 23 classic design patterns described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Composite pattern works and when it should be applied.

Composite: Basic Idea

The first thing we need to look at is the definition offered by the book from the Gang of Four:

“Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.”

Next, we need to look at the UML class diagram of this pattern to understand each of the elements that compose it.

The Composite pattern typically includes the following main elements:

• Component: Defines the interface for objects in the composition. It declares an interface for accessing and managing children of composite objects.
• Leaf: Represents leaf objects in the composition. A leaf has no children. It implements the operations defined in the component interface.
• Composite: Defines the behavior of components that have children. It stores subcomponents and provides the implementation of operations related to children, such as adding, removing, and accessing child components.
• Client: Manipulates the objects in the composition through the component interface.

With these elements, the Composite pattern allows building tree-shaped object structures that can be treated uniformly, whether it is an individual object or a composition of objects.

When to Use the Composite Pattern

The Composite pattern is an excellent solution when faced with a system where a hierarchical structure of objects needs to be managed uniformly. Here are some common situations where the use of the Composite pattern can be beneficial:

1. Hierarchical Structures: When you need to represent object hierarchies, such as menus, organizations, or scene graphs. The Composite pattern facilitates the creation and manipulation of these hierarchies, allowing composite objects to contain other composite objects or leaves.
2. Uniform Treatment of Objects: If you want clients to treat individual objects and compositions of objects in the same way, the Composite pattern is ideal. This simplifies client code, as it does not need to differentiate between simple and composite objects.
3. Flexibility and Scalability: By using the Composite pattern, you can easily add new types of components. This facilitates the extension and modification of the structure without needing to change the code that interacts with it.

In summary, the Composite pattern is useful in situations where there is a need to handle hierarchical structures of objects uniformly, simplify interaction with these objects, and enhance the flexibility and scalability of the system.

Let’s now look at examples of applying this pattern.

Composite Pattern: Examples

Next, we will illustrate the composite pattern with two examples:

1. Basic Structure of the Composite Pattern: In this example, we will translate the theoretical UML diagram into TypeScript code to identify each of the classes involved in the pattern.
2. Recipe Book: We will have a set of ingredients that make up a recipe, but within a recipe, we can also have another recipe that must be made prior to our delicious dish.

Example 1: Basic Structure of the Composite Pattern

As always, the starting point is the UML class diagram. This UML class diagram is the same as we explained at the beginning of the post, and to streamline the post, we will not explain it again as such. However, we will begin to see its implementation step by step.

Let’s start with the Component interface. This interface defines the contract that any component in the system must follow. In this case, it only has one method, operation, which is implemented by both leaf nodes and composite nodes.

export interface Component {
    operation(): void;
}

The next class is Leaf, this class implements the Component interface. The Leaf class represents the final objects in the composition, which have no children. The operation method in the Leaf class simply performs the leaf-specific operation.

import { Component } from "./component";

export class Leaf implements Component {
    operation(): void {
        console.log("Leaf operation.");
    }
}

The next class is Composite. This class also implements the Component interface. It can have children and defines operations related to its children. The Composite class has methods for adding and removing children, and its operation method iterates over all its children and calls their operation method.

import { Component } from "./component";

export class Composite implements Component {
    private children: Component[] = [];

    // Add a child to the list of children
    addChild(child: Component): void {
        this.children.push(child);
    }

    // Remove a child from the list of children
    removeChild(child: Component): void {
        const index = this.children.indexOf(child);
        if (index !== -1) {
            this.children.splice(index, 1);
        }
    }

    // Implement the operation defined in the Component interface
    operation(): void {
        console.log("Composite operation.");
        this.children.forEach(child => child.operation());
    }
}

The Composite class manages a list of children who are also Component objects. This allows for a tree structure where each node in the tree is either a Leaf or a Composite. Now, let’s see how to use this pattern from the Client class.

import { Component } from "./component";
import { Composite } from "./composite";
import { Leaf } from "./leaf";

const leaf1: Component = new Leaf();
const leaf2: Component = new Leaf();
const leaf3: Component = new Leaf();
const composite1: Component = new Composite();
const composite2: Component = new Composite();

// Build the tree structure
(composite1 as Composite).addChild(leaf1);
(composite1 as Composite).addChild(leaf2);
(composite2 as Composite).addChild(leaf3);
(composite2 as Composite).addChild(composite1);

// Call the operation on the root composite
composite2.operation();

In the client code, we instantiate leaf and composite objects and build a tree structure. We add child components to composite objects, creating a hierarchy. Finally, we call the operation method on the root composite, which propagates the call to its children and so on, performing operations recursively.

Example 2: Recipe Book without the Composite Pattern

Imagine we want to create a system to manage cooking recipes, where each recipe can consist of ingredients and other recipes. Without applying the Composite pattern, we would have a rigid and error-prone implementation. Below is the implementation of a recipe system without using the Composite pattern.

If we look at the UML class diagram, we first encounter the Ingredient class, which consists of two attributes: the name of the ingredient and the amount. The showDetails method is a simple toString method to display the information.

On the other hand, we see the Recipe class, which has attributes for the name of the recipe, a collection of ingredients, which are related through a composition relationship. Additionally, we have a set of recipes needed to make this recipe. Here is where we see a recursive relationship in the recipes. Moreover, the methods we need right now are quite simple: we have methods to add ingredients (addIngredient) and to add recipes to this entity (addRecipe), and a method to display the recipe details called showDetails.

Let’s look at the implementation of this initial solution that does NOT use the Composite pattern.

export class Ingredient {
    name: string;
    amount: string;

    constructor(name: string, amount: string) {
        this.name = name;
        this.amount = amount;
    }

    showDetails(): string {
        return `Ingredient: ${this.name}, Amount: ${this.amount}`;
    }
}

The first point is to look at the Ingredient class, which is a simple class where we only have the two attributes mentioned earlier: name and amount, which are received through the constructor. On the other hand, the showDetails method displays the information of the ingredient.

import { Ingredient } from './ingredient';

export class Recipe {
    name: string;
    ingredients: Ingredient[] = [];
    recipes: Recipe[] = [];

    constructor(name: string) {
        this.name = name;
    }

    addIngredient(ingredient: Ingredient): void {
        this.ingredients.push(ingredient);
    }

    addRecipe(recipe: Recipe): void {
        this.recipes.push(recipe);
    }

    showDetails(): string {
        let details = `Recipe: ${this.name}\n`;

        this.ingredients.forEach(ingredient => {
            details += `  ${ingredient.showDetails()}\n`;
        });

        this.recipes.forEach(recipe => {
            details += `  ${recipe.showDetails()}`;
        });

        return details;
    }
}

The next element in this solution is the Recipe class where we have the private attributes name and a list of ingredients, which are obvious for a recipe. Additionally, we have a recursive relationship through an attribute recipes, which is a collection of recipes. The constructor is quite simple as it only receives the name of the recipe, and then we have two methods that allow adding ingredients ( addIngredient) and recipes (addRecipes).

The class ends with the showDetails method, where we encounter two for loops to display the information of the ingredients and the recipes contained in this recipe.

However, at this point, we can detect serious problems that may not seem important at first, but as the project grows, they will cause significant issues in the software:

1. Method Redundancy: The Recipe class has two separate methods for adding components to its class, namely the addIngredient and addRecipe methods. These methods introduce redundancy and complicate the code because the logic for adding components is duplicated and exactly the same.
2. Difficulty Extending Functionality: If in the future another type of component, like Utensil, needs to be added, it would be necessary to add another method (addUtensil) and modify the showDetails logic to include it. This makes the code less flexible and harder to maintain.
3. Violation of the Liskov Substitution Principle: The addIngredient and addRecipe methods do not allow for treating all components uniformly. This violates the Liskov Substitution Principle, one of the SOLID principles, since Recipe and Ingredient cannot be used interchangeably through a common interface.

These are precisely the problems we are going to solve with the Composite pattern. However, before we move on to the solution, let’s also look at the client code that would use this solution.

import { Ingredient } from "./ingredient";
import { Recipe } from "./recipe";

const ingredient1 = new Ingredient("Flour", "2 cups");
const ingredient2 = new Ingredient("Eggs", "3");
const recipe = new Recipe("Cake");
recipe.addIngredient(ingredient1);
recipe.addIngredient(ingredient2);

const ingredient3 = new Ingredient("Milk", "1 cup");
const compositeRecipe = new Recipe("Cake with Milk");
compositeRecipe.addRecipe(recipe);
compositeRecipe.addIngredient(ingredient3);

console.log(compositeRecipe.showDetails());

First, we see that we are creating several ingredients and a recipe for a cake. We have to link the ingredients to the cake through the addIngredient method.

On the other hand, if we want to create a Cake with Milk, we need to create a new recipe, add the Milk that we didn’t have in the previous recipe, and for the Cake with Milk, we need to nest the previously configured cake recipe. Here we can see that to add components, we don’t have a common interface, which even makes it difficult to work with the recipes.

Having outlined all the problems with this solution and the code we’ve analyzed, let’s introduce the Composite pattern to it.

Example 2: Recipe Book using the Composite Pattern

To address the solution, the first thing we need to look at is how the UML class diagram of the problem evolves with the application of the Composite pattern.

Let’s start by noting that we now have an interface named RecipeComponent, which defines the showDetails method as the common interface for all components. Both ingredients and recipes implement this interface. The Ingredient class does not undergo any changes in this solution. In fact, the Ingredient class is equivalent to the Leaf class in the pattern. On the other hand, the Recipe class changes considerably in the solution because it will now have an array of objects that satisfy the RecipeComponent interface. These will be both ingredients and recipes. Additionally, we will no longer have two methods to add ingredients or recipes; instead, there will be a single method called addComponent to perform these operations, and the showDetails method will be implemented.

Of course, let’s go through the code step by step to see how the code has evolved and how the issues have been resolved.

export interface RecipeComponent {
    showDetails(): string;
}

Let’s start by looking at the interface for the components. This interface will be implemented by both ingredients and recipes. Initially, we only define the showDetails method.

import { RecipeComponent } from "./recipe-component";

export class Ingredient implements RecipeComponent {
    name: string;
    amount: string;

    constructor(name: string, amount: string) {
        this.name = name;
        this.amount = amount;
    }

    showDetails(): string {
        return `Ingredient: ${this.name}, Amount: ${this.amount}`;
    }
}

If we look at the Ingredient class, it is exactly the same as before, except that now we implement the RecipeComponent interface, which we did previously as well. Reviewing the class, we see that we have two attributes for each ingredient: the name and the amount. These two attributes are received through the constructor to create each instance, and finally, we have the showDetails method, which is responsible for displaying the information of each ingredient.

import { RecipeComponent } from "./recipe-component";

export class Recipe implements RecipeComponent {
    name: string;
    components: RecipeComponent[] = [];

    constructor(name: string) {
        this.name = name;
    }

    addComponent(component: RecipeComponent): void {
        this.components.push(component);
    }

    showDetails(): string {
        let details = `Recipe: ${this.name}\n`;

        this.components.forEach(component => {
            details += `  ${component.showDetails()}\n`;
        });

        return details;
    }
}

On the other hand, if we look at the class corresponding to the recipes, here we do find changes. We start by seeing that the attributes are now the name of the recipe and an array of objects that satisfy the RecipeComponent interface, meaning they could be both ingredients and recipes. The constructor only requires the name of the recipe and nothing else. Furthermore, we no longer have two methods to manage recipes and ingredients; instead, with a single method like addComponent, we add both recipes and ingredients, eliminating redundancy in the code. The last method we need to look at is showDetails. Now, instead of having several loops, we just need to traverse the data structure we have and invoke the showDetails method because we know that all objects satisfy the interface that introduces this method.

import { Ingredient } from "./ingredient";
import { Recipe } from "./recipe";

// Usage
const ingredient1 = new Ingredient("Flour", "2 cups");
const ingredient2 = new Ingredient("Eggs", "3");
const recipe = new Recipe("Cake");
recipe.addComponent(ingredient1);
recipe.addComponent(ingredient2);

const ingredient3 = new Ingredient("Milk", "1 cup");
const compositeRecipe = new Recipe("Cake with Milk");
compositeRecipe.addComponent(recipe);
compositeRecipe.addComponent(ingredient3);

console.log(compositeRecipe.showDetails());

We also need to look at the client class that uses the pattern. The first thing we would do now is to create instances of ingredients and the cake recipe again, which would have the two ingredients added through the addComponent method. Now, if we want to create a cake with milk, we simply need to create an ingredient that would be the milk and the cake with milk recipe, which would receive both the ingredient and the cake through the addComponent method. Finally, we would see the result through the showDetails method.

Now let’s move on to analyze how the Composite pattern relates to other design patterns.

Composite Pattern: Relationship with Other Patterns

The Composite pattern integrates effectively with several other design patterns, each complementing its capabilities and extending its applicability in building complex and scalable systems. Below is a description of how the Composite pattern relates to other design patterns:

Decorator

The Composite and Decorator patterns both structure objects recursively, allowing both simple and composite components to be treated uniformly. Both patterns use a common interface for the objects they manage. In Composite, leaves and composites implement the same interface. In Decorator, the decorated object and the decorator share the same interface.

While Composite is used to represent part-whole hierarchies, Decorator is employed to add additional responsibilities to an object dynamically without changing its structure. Decorator can be used in combination with Composite to add extra behaviors to components of a Composite structure.

Iterator

The Iterator pattern complements the Composite pattern by providing a uniform way to traverse elements of the composite structure without knowing its internal structure. Both patterns promote a common interface for handling collections of objects. Composite organizes objects into a hierarchy, while Iterator allows for sequential traversal of these objects.

Composite is used to build complex hierarchical structures, and Iterator can be used with Composite to navigate this structure transparently, facilitating manipulation and access to the components.

Visitor

The Visitor pattern allows for defining new operations on a Composite structure without modifying the component classes, facilitating the extension of functionalities. Both patterns operate on an object structure. Composite facilitates part-whole hierarchies management, while Visitor facilitates the execution of operations on the components of that structure.

Composite is used to create object hierarchies, while Visitor can be applied to these hierarchies to define new operations, allowing operations to change without altering the component classes.

Flyweight

The Flyweight pattern can be used with Composite to efficiently handle a large number of similar objects by sharing intrinsic states. Both patterns aim to optimize resource usage. Composite organizes objects into hierarchical structures, and Flyweight reduces memory usage by sharing common components among objects.

Composite is used to organize objects into part-whole hierarchies. Flyweight can be used within a Composite to reduce the memory needed by sharing common components among multiple instances.

Builder

The Builder pattern can be used to construct Composite structures incrementally and in a controlled manner. Both patterns simplify the creation of complex structures. Composite organizes objects into hierarchies, and Builder facilitates the step-by-step construction of these hierarchies.

Composite is used to represent complex hierarchical structures, while Builder can be used to assemble these structures in a controlled way, ensuring that each component is added correctly.

Chain of Responsibility

The Chain of Responsibility pattern can be used in a Composite structure to propagate requests through the components of the hierarchy. Both patterns handle distributed responsibilities. Composite organizes objects into a part-whole structure, and Chain of Responsibility allows for request handling through a chain of objects.

Composite is used to organize objects in a hierarchy. Chain of Responsibility can be used to handle requests within this structure, allowing requests to propagate from one component to another until one that can handle them is found.

Conclusions

Overall, the Composite pattern is a valuable tool for designing systems that manage complex hierarchies of objects, especially when aiming for:

• Uniform Treatment of Objects and Compositions: It allows for the uniform treatment of individual objects (leaves) and combinations of objects (composites). This simplifies the handling of complex hierarchical structures by providing a common interface.
• Flexibility and Reusability: Individual and composite components implement the same interface, allowing for easy reuse and reorganization of components. This facilitates the modification and expansion of the structure without affecting other parts of the system.
• Ease of Maintenance: By treating individual and composite objects in the same manner, the code becomes easier to maintain and understand. Modifications to the structure or components can be made without affecting the rest of the system.
• Simplification of Client Code: Clients can treat composite and simple objects in the same way, reducing the complexity of the code that interacts with the hierarchical structure.

However, the use of the Composite pattern also has some disadvantages:

• Increased Implementation Complexity: The composite structure can make the system design more complex, especially when managing multiple levels of composition and aggregation.
• Potential Performance Loss: Navigating and managing a deep hierarchical structure can introduce performance overhead, particularly if aggregation and removal operations are performed frequently.
• Difficulty in Restricting Components: In some cases, it may be challenging to restrict the types of components that can be added to a composite, which could lead to a less secure or less clear design.

The most important thing about the Composite pattern is not its specific implementation, but the ability to recognize the problem that this pattern can solve and when it can be applied. The specific implementation is not that important, as it will vary depending on the programming language used.

See this GitHub repo for the full code.

There are 23 classic design patterns described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Flyweight pattern works and when it should be applied.

Proxy: Basic Idea

The first thing we will do, as with the other design patterns, is to look at the definition offered by the book “Design Patterns” by the Gang of Four:

Provide a surrogate or placeholder for another object to control access to it.

A proxy can perform additional operations (such as controlled access, lazy loading, etc.) before accessing the real object. The most common uses of the proxy pattern according to its purpose are as follows:

• Virtual Proxy: controls access to resources that are expensive to create, such as objects that require a lot of memory or processing time. It is used for lazy loading of an object.
• Protection Proxy: controls access to an object by providing different permissions to different users.
• Remote Proxy: allows access to an object that resides in a different address space. For example, this proxy could handle all the necessary communication between a client and a server on different machines.

As we have done in the entire series of pattern videos, let’s start by looking at the UML class diagram to understand each of the elements of it.

1. Subject: Defines a common interface for RealSubject and Proxy so that Proxy can be used in place of RealSubject.
2. RealSubject: The real object that the proxy represents.
3. Proxy: Maintains a reference that allows the proxy to access the RealSubject. Provides an identical interface to that of Subject so it can substitute RealSubject. Controls access to RealSubject and can be responsible for its creation and deletion.

Now that we have a clear understanding of the basic structure, let’s see when this pattern is useful to us.

Proxy Pattern: When to Use

It The Proxy pattern is an excellent solution when we need to add a level of control or intermediation between the client and the real object. Here are some common situations where using the Proxy pattern can be beneficial:

1. Monitoring and Logging: If we need to record or monitor access to an object, a Proxy can intercept calls and add additional functionality, such as logging, without modifying the real object. This is useful for debugging, auditing, and usage analysis.
2. Access Control: When we need to control access to an object, such as restricting who can interact with it or under what conditions. For example, in a system with different permission levels, a Protection Proxy can ensure that only authorized users can perform certain operations.
3. Lazy Loading: If creating an object is costly in terms of resources and time, a Virtual Proxy can defer the creation of the object until it is really necessary. This is useful for optimizing performance and reducing resource consumption.
4. Remote Access: In distributed applications where objects reside on different machines or processes, a Remote Proxy can handle all communication and data transfer, providing a local interface to the remote object. This simplifies interaction and hides the complexity of network communication.
5. Resource Optimization: When handling heavy objects or costly resources, a Proxy can manage the object’s lifecycle, such as creation and destruction, to optimize the use of system resources.

In summary, the Proxy pattern is useful in situations where additional control is needed, resource usage needs to be optimized, or interaction with remote objects needs to be facilitated. Now, let’s look at some examples of this pattern in application.

Proxy Pattern: Examples

Next, we will illustrate the proxy pattern with several useful use cases:

1. Basic Structure of the Proxy Pattern: In this example, we will translate the theoretical UML diagram into TypeScript code to identify each of the classes involved in the pattern.
2. From the basic schema, we will create different types of proxies to understand many of the uses, so we will implement the logger proxy, security proxy, lazy loading proxy, remote access proxy, and caching proxy.

Example 1: Basic Structure of the Proxy Pattern

As always, the starting point is the UML class diagram to define each of the elements. This first class diagram is the same as the one we explained at the beginning of the post, and we won’t repeat the explanation here to avoid making the post too long.

However, what we will do is review the implementation of it using the TypeScript programming language.

Let’s start with the Subject interface. This interface defines the contract that both the RealSubject and the Proxy must fulfill. This is evident since the proxy will intercept the RealSubject and must comply with the same interface.

interface Subject {
    operation(): void;
}

On one hand, the RealSubject class only implements the methods to fulfill the Subject interface.

class RealSubject implements Subject {
    operation(): void {
        console.log('RealSubject: Handling operation.');
    }
}

On the other hand, we see that the Proxy class has an instance of RealSubject through composition, and in this example, we will accomplish this through the constructor. Although we could have used an accessor method to perform this composition. If we focus on the operation method, which is the one we need to implement to satisfy the Subject interface, we are simply invoking the operation method of the Subject instance. Obviously, as we are showing it, we are doing absolutely NOTHING, but it is precisely here where we would have the interception of the real method, and where we would implement the logic that we want the proxy to perform.

class Proxy implements Subject {
    private realSubject: RealSubject;

    constructor(realSubject: RealSubject) {
        this.realSubject = realSubject;
    }

    operation(): void {
        // Different actions can be performed here
        this.realSubject.operation();
    }
}

Lastly, we would have the client that would interact directly with the Proxy and not with the RealSubject. However, to illustrate the difference in the client, it would be that initially, the client would interact directly with RealSubject, but when we introduce the Proxy pattern, we would switch to interacting with the Proxy class instead of the RealSubject class.

console.log('Client: Executing the client code with a real subject:');
const realSubject = new RealSubject();
realSubject.operation()

console.log('');

console.log('Client: Executing the same client code with a proxy:');
const proxy = new Proxy(realSubject);
proxy.operation();

Example 2: Different Types of Proxies

In this example, we are going to create five different types of proxies to cover various use cases where the Proxy pattern is useful. Our examples will be simple but will give us the intent of the pattern, which is what really matters: having a recurring problem and how the pattern can help us solve it.

The UML class diagram for this proposal would be as follows:

We start by seeing that we have the Subject interface and the RealSubject class, which remain exactly the same as in the previous case, an interface that defines the contract that both RealSubject and the proxies must fulfill.

On the other hand, we have a package with different Proxies. In our case, we start with the LoggingProxy class, which will act to monitor access to a subject, LazyProxy which will delegate the creation of the subject object until it is requested, RemoteProxy which will load objects from an external and remote environment such as a backend, and AccessProxy which focuses on validating that a user can access the object.

On the other hand, we have a different Subject and RealSubject, which we have called SubjectCache and RealSubjectCache because the interface is different. In this case, we will have a request operation that receives a parameter, and therefore the object to which we apply the proxy will be RealSubjectCache. Finally, we have the proxy called CacheProxy, which will store the subjects that are requested from an external resource, and if this subject has already been previously loaded, it will be stored to speed up its loading.

So, let’s start with the implementation of these proxies.

Logging Proxy

Let’s quickly review the Subject interface and the RealSubject to check that we still have a very simple interface, where a single operation called operation is defined, and as the RealSubject method implements this interface, we are just showing a trace message to know that we have passed through the RealSubject.

export interface Subject {
    operation(): void;
}

import { Subject } from "./subject.interface";

export class RealSubject implements Subject {
    operation(): void {
        console.log('RealSubject: Handling operation.');
    }
}

Now let’s start by looking at the first proxy, and the simplest of all we will see, this would be the LoggingProxy. This proxy is exactly the same as the book example (Gang of Four), but now in the operation method, we have added a private method called logAccess which would store or communicate to the monitoring system that the proxy has been accessed.

In our particular case, we will just show on the screen that we have accessed it, and the next thing the proxy would do is invoke the RealSubject method. That is, this proxy would only add extra functionality before executing the RealSubject method.

import { RealSubject, Subject } from "../subjects/";

export class LoggingProxy implements Subject {
    private realSubject: RealSubject;

    constructor(realSubject: RealSubject) {
        this.realSubject = realSubject;
    }

    operation(): void {
        this.logAccess();
        this.realSubject.operation();
    }

    private logAccess(): void {
        console.log('LoggingProxy: Logging access to RealSubject.');
    }
}

Access Proxy

The next proxy we address is AccessProxy, this proxy focuses on controlling which users or other elements with permission can access the RealSubject. For this example, the proxy stores a new private property that is the user’s role, which we communicate to the Proxy through the constructor.

If we now look at the operation method, we see that we have a guard clause. In this case, if the checkAccess is not satisfied, the method will automatically return a message indicating that access to the resource is not allowed. Otherwise, we can execute the RealSubject's operation method.

If we look at the private checkAccess method, there is the access logic to the RealSubject, in our case, it simply means that the user’s role should be admin.

import { RealSubject, Subject } from "../subjects/";

export class AccessProxy implements Subject {
    private realSubject: RealSubject;
    private userRole: string;

    constructor(realSubject: RealSubject, userRole: string) {
        this.realSubject = realSubject;
        this.userRole = userRole;
    }

    operation(): void {
        if (!this.checkAccess()) {
            return console.log('AccessProxy: Access denied.'); 
        }
        this.realSubject.operation();
    }

    private checkAccess(): boolean {
        console.log(`AccessProxy: Checking access for role ${this.userRole}.`);
        return this.userRole === 'admin';
    }
}

Lazy Proxy

Very similar in implementation that AccessProxy but with a very different objective, we have the LazyProxy. In this case, we will use the proxy to delay the creation of the RealSubject until the moment the operation method is executed.

First, we notice that this proxy does not receive the RealSubject through the constructor, but it is responsible for instantiating it in the operation method.

The first thing it does is check if the instance has a value other than null, in which case it is instantiated, and then the subject’s operation method is invoked.

import { RealSubject, Subject } from "../subjects/";

export class LazyProxy implements Subject {
    private realSubject: RealSubject | null = null;

    operation(): void {
        if (this.realSubject === null) {
            this.realSubject = new RealSubject();
        }
        this.realSubject.operation();
    }
}

Remote Proxy

The next proxy is a bit more complex than the previous one but follows the same idea. We are talking about the remote proxy.

In this proxy, if we look at the operation method, we would have a solution very similar to the previous one, but now instead of directly creating the RealSubject if the instance does not exist in the proxy, we invoke a method that will remotely connect to retrieve the RealSubject. The connectToRemote method simulates an HTTP request or an external resource. In this case, we connect to the URL passed as an argument to the fetch method. As we know, in JavaScript, this method returns a Promise, which we can wait for and retrieve its result from the external resource with the reserved word await. We then only check that the request to the external resource did not respond with the value ok, and in that case, we return an error, using a guard clause again.

We then simulate a small delay in the connection using promises and setTimeout. This code will not exist in production code because here we are only delaying execution for one second, to finally create the RealSubject. In a real scenario, the RealSubject would be constructed from the information retrieved from the requested HTTP resource.

import { RealSubject, Subject } from "../subjects/";

export class RemoteProxy implements Subject {
    private realSubject: RealSubject | null = null;
    private readonly remoteServerUrl: string = 'https://jsonplaceholder.typicode.com/posts/1';

    async operation(): Promise<void> {
        if (this.realSubject === null) {
            await this.connectToRemote();
        }
        if (this.realSubject) {
            this.realSubject.operation();
        }
    }

    private async connectToRemote(): Promise<void> {
        console.log('RemoteProxy: Connecting to remote server...');
        // Simulate HTTP request to connect to remote server

        const response = await fetch(this.remoteServerUrl);
        if (!response.ok) {
            return console.error('RemoteProxy: Failed to connect to remote server.');
        }

        // Simulate network delay
        await new Promise(resolve => setTimeout(resolve, 1000));
        console.log('RemoteProxy: Connected to remote server.');
        this.realSubject = new RealSubject(); 
    }
}

Cache Proxy

The last proxy example we will see is a bit more complex than the previous ones and would be building a cache of subject objects. So, the first thing we will see is the SubjectCache and RealSubjectCache interface, which differ from the previous one since now SubjectCache instead of having an operation method without parameters, we will have a request method that receives a resource argument of type string, and this function returns a promise of strings. We already know that this method will be asynchronous.

export interface SubjectCache {
    request(resource: string): Promise<string>;
}

import { SubjectCache } from  './subject-cache.interface';

export class RealSubjectCache implements SubjectCache {
    async request(resource: string): Promise<string> {
        // Simulate fetching resource from external API
        console.log(`RealSubject: Fetching resource from ${resource}`);
        // Simulate network delay
        await new Promise(resolve => setTimeout(resolve, 1000));
        return `Response from ${resource}`;
    }
}

The RealSubjectCache class, which is the real implementation of this interface, simply simulates that a request is being made to an external resource or API. To do this, we simulate a delay of one second until we return the String with a message from this Subject. In this use case, we do not want to go to the server and have a latency of one second or even more, and what we want is that if the Subject has already been queried, we do not request it again, but store it in a data structure. So, in CacheProxy, we have an attribute called cache, which is a Map that contains as a key a character string, which will be the resource, and as a value another character string, which will be the string we get in response.

We could also store an object in more advanced examples. Now if we look at the request method of the proxy, we can see that what is being done is a check through an if, where it is being checked if the cache has an entry with the resource key. If so, we are not invoking the RealSubject but returning the value we have stored, that is, we are improving the response time, in exchange for hardware resources such as memory for having the Map data structure.

On the other hand, if the resource has not been queried, what we will do is invoke the RealSubject method to get a response. Here we will have the same result as if we did not have the proxy, but immediately afterward we store the returned value in the data structure, and finally, the value is returned as well.

import { RealSubjectCache, SubjectCache } from "../subjects/";

export class CacheProxy implements SubjectCache {
    private realSubject: RealSubjectCache;
    private cache: Map<string, string> = new Map();

    constructor(realSubject: RealSubjectCache) {
        this.realSubject = realSubject;
    }

    async request(resource: string): Promise<string> {
        if (this.cache.has(resource)) {
            console.log(`CacheProxy: Retrieving response from cache for ${resource}`);
            return this.cache.get(resource)!;
        } else {
            const response = await this.realSubject.request(resource);
            console.log(`CacheProxy: Caching response for ${resource}`);
            this.cache.set(resource, response);
            return response;
        }
    }
}

And so far several types of proxies that have surely given you ideas and circumstances in which you can apply the pattern. Now let’s see how this pattern relates to other design patterns

Proxy Pattern: Relationship with Other Patterns

The Proxy pattern has connections with several other design patterns, as it can complement and enhance their functionality. Some of the most relevant relationships are:

• Decorator Pattern: The Decorator pattern and the Proxy pattern share a similar structure, as both patterns wrap an object to add functionality. However, while the Decorator focuses on dynamically adding additional behaviors, the Proxy focuses on controlling access to the object.
• Adapter Pattern: Both patterns wrap another object but with different purposes. The Adapter is used to transform one interface into another, making an object compatible with an interface it otherwise could not use. The Proxy, on the other hand, controls access to the object.
• Singleton Pattern: The Proxy can use the Singleton pattern to ensure that there is only one instance of the proxy, especially in situations where centralized control of access to a shared resource is desired.
• Factory Method Pattern: A Proxy can be created using the Factory Method pattern to manage the creation of proxies in a flexible and decoupled manner. This is useful for maintaining a clean and modular code structure.
• Flyweight Pattern: A Proxy can wrap a Flyweight object, providing additional control over access to shared objects. This is useful when more granular management of Flyweight objects is needed, such as memory management or lifecycle control.
• Composite Pattern: The Proxy can work with the Composite pattern to handle hierarchical structures of objects where access to subcomponents needs to be controlled individually. This can be useful in systems where the object structure is complex and detailed access control is required.

By leveraging these relationships with other patterns, the Proxy pattern can improve the modularity, scalability, and maintainability of a system while providing additional control over the access and management of objects.

Conclusions

The Proxy pattern offers a versatile and effective solution for systems that require additional control over object access. By providing an intermediary that handles various responsibilities such as access control, lazy loading, and remote communication, the Proxy pattern can significantly enhance the system’s security, performance, and flexibility.

The most important thing about the Proxy pattern is not its specific implementation, but the ability to recognize the problem that this pattern can solve and when it can be applied. The specific implementation is not that important, as it will vary depending on the programming language used.

See this GitHub repo for the full code.

There are 23 classic design patterns described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Flyweight pattern works and when it should be applied.

Flyweight: Basic Idea

First, let’s see the definition provided by the Gang of Four book:

A flyweight is a shared object that can be used in multiple contexts simultaneously. The flyweight acts as an independent object in each context; it’s indistinguishable from an instance of the object that is not shared.

On the other hand, flyweight objects cannot make assumptions about the context in which they operate. The key concept here is the distinction between intrinsic and extrinsic state. Intrinsic state is stored in the flyweight; it consists of information that is independent of the flyweight’s context, allowing it to be shared. Extrinsic state depends on the flyweight’s context and varies with it, therefore, it cannot be shared. Client objects are responsible for passing the extrinsic state to the flyweight when it is needed.

Next, let’s take a look at the UML class diagram for this pattern to understand each of its elements.

The Flyweight pattern typically includes the following elements:

• Flyweight: Defines the interface for objects that can be shared. It contains the intrinsic states that are shared among several objects.
• Concrete Flyweight: Implements the Flyweight interface and stores the intrinsic states. These objects are shared among multiple contexts.
• Unshared Concrete Flyweight: Represents objects that cannot be shared. Although they do not share their state, they can contain references to other Flyweight objects.
• Flyweight Factory: Manages a set of Flyweight objects. It ensures that Flyweight objects are shared properly and provides methods to obtain instances of Flyweights.
• Client: Maintains references to the Flyweights and calculates or stores the extrinsic states (those that are not shared and can vary between objects).

Flyweight Pattern: When to Use It

The Flyweight pattern is an excellent solution when dealing with systems that need to create and manage a large number of similar objects, which can result in high memory consumption if not managed properly. Below are some common situations where using the Flyweight pattern can be beneficial:

1. Objects with shared states: When we have a large number of objects that share significant parts of their state with each other, such as text, images, or similar data, the Flyweight pattern allows sharing these common states among multiple instances, thereby reducing memory consumption.
2. Reduction of resource consumption: If you want to reduce memory or other resource consumption in your system, the Flyweight pattern can be an effective solution. By sharing common parts of objects among multiple instances, unnecessary duplication of data is avoided, and system performance is optimized.
3. Facilitating object creation: The Flyweight pattern facilitates the creation and management of a large number of objects by reusing existing instances instead of creating new ones each time they are needed. This can be especially useful in situations where object creation is resource-intensive in terms of computational resources.

In summary, the Flyweight pattern is useful in situations where it is necessary to optimize memory and resource usage by sharing common parts of objects among multiple instances. Now, let’s look at examples of applying this pattern.

Flyweight Pattern: Examples

Next, we will illustrate the Flyweight pattern with two examples:

1. Basic Structure of the Flyweight Pattern: In this example, we will translate the theoretical UML diagram into TypeScript code to identify each of the classes involved in the pattern.
2. A football statistics system: We will have statistics for different teams, with hundreds of players where we need to objects to define the positions of the players and the teams they belong to. Here, we can see that we will have many objects that are shared, such as the specific positions of the players or the team.

Example 1: Basic Structure of the Flyweight Pattern

As always, the starting point is the UML class diagram to define each of the elements. This first class diagram is the same one we explained at the beginning of the post, and we will not repeat the explanation here to avoid making the post too long.

However, we will start implementing it step by step using the TypeScript programming language.

Let’s start with the Flyweight interface. This interface defines the contract that any Flyweight in the system must follow. In this case, it only has one method called operation, which receives the extrinsic state of our problem as a parameter. This method is implemented by the concrete flyweights, both the shared and the unshared ones.

export interface Flyweight {
    operation(extrinsicState: any): void;
}

The next class is the ConcreteFlyweight. In this class, we can see that we have a private attribute, which is the intrinsic state of our problem. As always, to simplify the example, this attribute is of type string. This state is received as a constructor parameter to store it internally in this class. Finally, we have the implementation of the operation method, which receives the extrinsic state and performs a console.log showing both states. Obviously, here we would have the business logic for our problem.

import { Flyweight } from "./flyweight";

export class ConcreteFlyweight implements Flyweight {
    private intrinsicState: string;

    constructor(intrinsicState: string) {
        this.intrinsicState = intrinsicState;
    }

    public operation(extrinsicState: any): void {
        console.log(`ConcreteFlyweight: Intrinsic State = ${this.intrinsicState}, Extrinsic State = ${extrinsicState}`);
    }
}

On the other hand, the UnsharedConcreteFlyweight class is the representation of the objects that are not shared in our problem. If we look at this class, we have a small variation; instead of having the intrinsic state stored, we have the entire state of the object. Obviously, again to simplify the example, it has been modeled as a string, but the conceptual difference is quite significant between Flyweight that share state and those that do not share state. Lastly, we have the implementation of the operation method, which displays the information of the allState attribute and the extrinsic state.

import { Flyweight } from "./flyweight";

// Unshared Concrete Flyweight
export class UnsharedConcreteFlyweight implements Flyweight {
    private allState: string;

    constructor(allState: string) {
        this.allState = allState;
    }

    public operation(extrinsicState: any): void {
        console.log(`UnsharedConcreteFlyweight: All State = ${this.allState}, Extrinsic State = ${extrinsicState}`);
    }
}

Up to this point, we have the Flyweight pattern by definition. However, in most cases, this pattern includes a factory class that is responsible for creating the Flyweight objects. And it is precisely this class that we will look at next.

import { ConcreteFlyweight } from "./concrete-flyweight";
import { Flyweight } from "./flyweight";

// Flyweight Factory
export class FlyweightFactory {
    private flyweights: Map<string, Flyweight> = new Map();

    public getFlyweight(key: string): Flyweight {
        if(this.flyweights.has(key)){
            console.log(`FlyweightFactory: Reusing existing flyweight for key = ${key}`);
            return this.flyweights.get(key)!;
        }
        
        this.flyweights.set(key,  new ConcreteFlyweight(key));
        console.log(`FlyweightFactory: Created new flyweight for key = ${key}`);
        return this.flyweights.get(key)!;
    }

    public listFlyweights(): void {
        console.log(`FlyweightFactory: I have ${this.flyweights.size} flyweights:`);
        for (const [key, _] of this.flyweights) {
            console.log(key);
        }
    }
}

In this class, we need to have a data structure where we store the different Flyweight objects. In our case, we are using a map where the key is a string identifier, and the value is the stored Flyweight object.

The getFlyweight method is the key to this factory because it takes the key as an argument to retrieve the object from the data structure. As we can see in the first control block of the code, the if statement checks whether the data structure contains the object we are looking for, and if it does, we simply return it.

If we do not have the object in the data structure, a new Flyweight object is created using the ConcreteFlyweightconstructor and stored in our data structure. The method concludes by returning the object we just created.

Therefore, we are implementing a small cache that will streamline the process of creating and retrieving objects. If the object already exists, we retrieve the one we have in memory and do not create duplicate objects. If the object does not exist, it is created only once.

The next method in the class, listFlyweights, simply iterates over the data structure where we have all the objects and displays the objects contained within it. We could have implemented any other business logic.

import { FlyweightFactory } from "./flyweight-factory";
import { UnsharedConcreteFlyweight } from "./unshared-flyweight";

const factory = new FlyweightFactory();

// Create and use shared flyweights
const flyweight1 = factory.getFlyweight('A');
flyweight1.operation('First Call');

const flyweight2 = factory.getFlyweight('B');
flyweight2.operation('Second Call');

const flyweight3 = factory.getFlyweight('A');
flyweight3.operation('Third Call');

// Create and use unshared flyweights
const unsharedFlyweight1 = new UnsharedConcreteFlyweight('Unique State');
unsharedFlyweight1.operation('Fourth Call');

factory.listFlyweights();

Finally, let’s look at the client code that uses the design pattern. In the code, the first thing we do is create the factory, which is responsible for managing the Flyweight objects. Next, we retrieve an object with the value A. Internally, the pattern will create this object since it does not exist and store it in the data structure. Then, we can use the operation method. We do the same with the object with the value B. The application of the pattern comes when creating the third object, where we retrieve the value A, and in this case, no more resources are consumed since it is obtained directly from the data structure instead of being instantiated again.

On the other hand, showing that the instance of objects that do not share the state would be as simple as making instances of these objects and using the defined methods. To conclude, we show all the objects instantiated in the data structure through the listFlyweights method, and we can see that the object with the value A appears instantiated only once in our problem

Example 2: Football Player Statistics Database without the Flyweight Pattern

In this example, we are going to create a database of football players where each player will have instances of other objects such as their positions and the team they belong to. Additionally, the players will have their own statistics on their performance in official matches.

Considering this problem, the UML class design that can be proposed is as follows:

We can observe that we would have the Player class with its own attributes, such as name, position, team, and statistics. The attributes position, team, and statistics are not primitives but objects that have different attributes, which, of course, could have more logic and methods, implement interfaces, etc. However, as always, we are simplifying to properly understand the pattern. But at first glance, we can see that we have the Player class and, through composition, we encounter three classes that are related to it. These classes depend on the Player, meaning that if the Player disappears, the objects in the composition are also destroyed.

The client of this application is called SportsSimulator, which is the class that would have the data structure storing all the instances of the players and some methods to manage this data structure, such as addPlayer, which receives the arguments for creating players, and the displayPlayers method, which lists all the players in the software. We can observe that SportsSimulator is not responsible for creating objects such as position, team, or statistics but rather receives the information from some data source. The only thing we can know and guarantee is that the data has the corresponding attributes to be well-formed. This has been modeled with the package of interfaces, where we find the interfaces for position, team, and statistics.

Let’s proceed to see the implementation of this first solution, which does NOT use the Flyweight pattern, to detect where the resource leak is that we could improve with the pattern.

The first class we need to look at is the Player class, which is quite simple. If we observe, we have the four attributes that make up a Player, and through the constructor, we receive the parameters that allow us to internally store each attribute of this object. Additionally, we include a toString method, which we have renamed as displayInfo, that simply shows the information of the object.

import { Position } from "./position";
import { Stats } from "./stats";
import { Team } from "./team";

export class Player {
    private name: string;
    private position: Position;
    private team: Team;
    private stats: Stats;

    constructor(name: string, position: Position, team: Team, stats: Stats) {
        this.name = name;
        this.position = position;
        this.team = team;
        this.stats = stats;
    }

    public displayInfo(): void {
        console.log(`Player - Name: ${this.name}, Position: ${this.position.name} (${this.position.role}), Team: ${this.team.name} (Coach: ${this.team.coach}), Stats: [Goals: ${this.stats.goals}, Assists: ${this.stats.assists}, Matches: ${this.stats.matches}]`);
    }
}

On the other hand, the Position, Team, and Stats classes do not contain any logic. Again, we repeat, this is didactic, and they should make sense as such to exist, but to simplify, we can see that they simply store the corresponding attributes of each type of object when they are constructed.

export class Position {
    constructor(public name: string, public role: string) {}
}

export class Stats {
    constructor(public goals: number, public assists: number, public matches: number) {}
}

export class Stats {
    constructor(public goals: number, public assists: number, public matches: number) {}
}

The next class is SportsSimulator, which is responsible for storing the data structure. In this case, we would have an array of Players, which are built in the addPlayer method itself. This method receives as a parameter the necessary information to create instances of all the objects. However, what it receives are objects that satisfy the interface of Position, Team, and Stats, but these objects it receives are not instances of classes, but simply data.

Therefore, the three objects that the instance of the Player class required are created, and once created, they are added to the data structure.

import { IPosition, IStats, ITeam } from "./interfaces";
import { Player, Position, Stats, Team } from "./models";

export class SportsSimulator {
    private players: Player[] = [];

    public addPlayer(name: string, position: IPosition, team: ITeam, stats: IStats): void {
        const positionPlayer = new Position(position.name, position.role);
        const teamPlayer = new Team(team.name, team.coach);
        const statsPlayer = new Stats(stats.goals, stats.assists, stats.passes);

        const player = new Player(name, positionPlayer, teamPlayer, statsPlayer);
        this.players.push(player);
    }

    public displayPlayers(): void {
        this.players.forEach(player => player.displayInfo());
    }
}

As mentioned earlier, the interfaces simply specify the attributes that the plain objects passed as arguments must contain. We have done it this way because in TypeScript, we can quickly create plain objects, which allows us to avoid having a method signature for addPlayer with all the attributes of player, position, team, and statistics separated, but instead having them grouped by plain objects.

export interface IPosition {
    name: string;
    role: string;
};

export interface ITeam {
    name: string;
    coach: string;
};

export interface IStats {
    goals: number;
    assists: number;
    passes: number;
};

Finally, we need to see the client code that uses all these classes.

import { IPosition, IStats, ITeam } from "./interfaces";

import { SportsSimulator } from "./sports-simulator";

// Client Code
const simulator = new SportsSimulator();

const forward: IPosition = {name: 'Forward', role: 'Attacker'};
const midfielder: IPosition = {name: 'Midfielder', role: 'Support'};
const defender: IPosition = { name: 'Defender', role: 'Defender'};
const goalkeeper: IPosition = {name: 'Goalkeeper', role: 'Goalkeeper'};

const positions = [goalkeeper, defender, midfielder, forward]

const teams: ITeam[] = [
    { name: "New Team", coach: "Roberto Sedinho" },
    { name: "Furano FC", coach: "Koujiro Hyuuga" },
    { name: "Toho Academy", coach: "Kira Hiroto" },
    { name: "Nankatsu SC", coach: "Tsubasa Ozora" },
    { name: "Otomo FC", coach: "Shingo Aoi" },
    { name: "Hirado FC", coach: "Hajime Taki" },
    { name: "Mamoru United", coach: "Taro Misaki" },
    { name: "Meiwa FC", coach: "Jun Misugi" }
];

const captainTsubasaCharacters: string[] = [
    "Tsubasa Ozora",
    "Koujiro Hyuuga",
    "Genzo Wakabayashi",
    "Taro Misaki",
    "Shingo Aoi",
    "Hikaru Matsuyama",
    "Jun Misugi",
    "Ken Wakashimazu",
    "Kazuo Tachibana",
    "Masao Tachibana",
    "Ryo Ishizaki",
    "Kojiro Hyuga",
    "Teppei Kisugi",
    "Hiroshi Jito",
    "Shun Nitta",
    "Mamoru Izawa",
    "Hanji Urabe",
    "Shingo Takasugi",
    "Mitsuru Sano",
    "Makoto Soda"
];


for(let i = 0; i < 25*teams.length -1; i++){
    const team = teams[i % teams.length];

    const position = positions[i % positions.length];
    const playerName = captainTsubasaCharacters[i % captainTsubasaCharacters.length];
    const stats: IStats = {
        goals: Math.floor(Math.random() * 20),
        assists: Math.floor(Math.random() * 20),
        passes: Math.floor(Math.random() * 20),
    };

    simulator.addPlayer(playerName, position, team, stats);
}

simulator.displayPlayers();

The first thing we have to do is create the sports simulator. To do this, we simply need to instantiate the SportsSimulator class. Next, we have the data we are going to use in the problem. This data can come from any data source, whether it’s integration files, databases, or even entered by the user. So, first, we define the positions, which would be forward, midfielder, defender, and goalkeeper.

Next, we define exactly the same but for the teams. We would have an array of team objects that satisfy the conditions of having a name and a coach. If you’ve noticed the names of the teams, our database is based on the anime series Captain Tsubasa. So, we need to reflect the names of the players as they appeared in the original version of the anime.

The last of our client code is a simple loop that is creating the necessary information for each team to have twenty five players. For that, we simply iterate to retrieve the information and send it to the simulator through the addPlayer method, and that’s where our object-oriented design would begin. Obviously, as we have more and more players, we will have more resources consumed by the instantiation of objects.

So far, there wouldn’t be a problem until one day the software needs more memory and we have to redesign it, which is exactly what we are going to do, but using the Flyweight pattern.

Example 2: Football Player Statistics Database using the Flyweight Pattern

The problems that arise in the solution without the Flyweight pattern are as follows:

1. Excessive memory usage: When many similar objects are created, each instance occupies its own space in memory. This can lead to very high memory consumption, especially if the objects have attributes that are repeated in multiple instances.
2. Data redundancy: In the absence of the Flyweight pattern, data that is common to multiple objects is duplicated in each instance. This not only increases memory usage but also introduces redundancy that can complicate data maintenance and updating.
3. Degradation of the system when used: Handling a large number of individual objects can degrade application performance, both in terms of processing time and resource consumption. Operations involving the manipulation of these objects can become slow and inefficient.
4. Difficulty in resource management: Without the Flyweight pattern, managing resources shared among multiple instances of objects becomes more complicated. This can lead to consistency and synchronization problems, especially in concurrent or distributed applications. Implementing the Flyweight pattern can mitigate these problems by allowing the sharing of objects where possible, reducing redundancy, and optimizing memory and resource usage. Let’s start by seeing how the UML class diagram evolves.

Let’s start by looking at the Player class. This class now does not directly relate to the Position and Team classes. Instead, there is now an intermediate class called PositionFlyweight and TeamFlyweight, each of which contains an aggregation of the Position and Team classes. Both flyweight classes implement the flyweight interface, which simply has a method called display to show information. These classes could be omitted if we didn’t have extrinsic states, but we’re demonstrating the pattern with different elements that could disappear depending on specific circumstances and problems.

Another key point in the diagram is that we have an abstract class that defines the different object factories. The flyweightFactory class is composed of a Map of objects that satisfy the Flyweight interface. This abstract class is extended by the PositionFlyweight and TeamFlyweight classes, which do have concreteness in their data structure. In one case, they store objects of the PositionFlyweight class, and in the other, objects of the TeamFlyweight class. Both implement the getFlyweight method, which allows us to create a new PositionFlyweight or TeamFlyweight object or retrieve it from the data structure.

As an exercise or appreciation of how design patterns intertwine, this method has an algorithm in which all steps are similar except one, which could allow us to implement the template-method design pattern, as we have seen in another post. However, we will duplicate code to simplify this example, as we are focusing on the flyweight pattern and not another. But what’s important is that we understand the purpose of each design pattern so that when they arise, we can think about how to adapt it to our problem.

Finally, we see that we have the SportsSimulator class, which will make use of both factories and will have the data structure of the players. Similarly to the previous example, the data will come from a data source where we only have the attributes without instantiation, and we can only guarantee that they have a series of attributes using the package of interfaces that has been defined.

Alright, let’s proceed to gradually review the implementation and how it has changed compared to the previous example to improve the application’s performance.

Let’s start with the code of the Player class, which instead of directly receiving Position and Team objects, now receives instances of PositionFlyweight and TeamFlyweight objects. Since Stats objects are not reused and are different for each class, they still maintain their direct relationship with the Player class. The displayInfo method is practically the same, only updating the invocation of the display method of the positionFlyweight object.

The Stats class undergoes no modification compared to the previous example since we are not applying any pattern or improvement there. This is because the statistics will not be reused among different players as the probability of reusing an object is low, and we would not benefit from this design pattern.

import { PositionFlyweight } from "../position-flyweight";
import { Stats } from "./stats";
import { TeamFlyweight } from "../team-flyweight";

export class Player {
    private name: string;
    private positionFlyweight: PositionFlyweight;
    private teamFlyweight: TeamFlyweight;
    private stats: Stats;

    constructor(name: string, positionFlyweight: PositionFlyweight, teamFlyweight: TeamFlyweight, stats: Stats) {
        this.name = name;
        this.positionFlyweight = positionFlyweight;
        this.teamFlyweight = teamFlyweight;

        this.stats = stats;
    }

    public displayInfo(): void {
        console.log(`Player - Name: ${this.name}, Stats: [Goals: ${this.stats.goals}, Assists: ${this.stats.assists}, Matches: ${this.stats.matches}]`);
        this.positionFlyweight.display(this.stats);
    }
}

So, let’s move on to see the PositionFlyweight and TeamFlyweight classes.

import { Flyweight } from "./flyweight";
import { Position } from "./models";

export class PositionFlyweight implements Flyweight {
    #position: Position; // Intrinsic State

    constructor(position: Position) {
        this.#position = position;
    }

    public display(extrinsicState: any): void {
        console.log(`Position: ${this.#position.name} (${this.#position.role})`);
    }

    public position(): Position {
        return this.#position;
    }
}

import { Flyweight } from "./flyweight";
import { Team } from "./models";

export class TeamFlyweight implements Flyweight {
    #team: Team; // Intrinsic State

    constructor(team: Team) {
        this.#team = team;
    }

    public display(extrinsicState: any): void {
        console.log(`Team: ${this.#team.name} (${this.#team.coach})`);
    }

    public team(): Team {
        return this.#team;
    }
}

Both classes are very similar, as they simply have an object of the class they are encapsulating, Position or Team, which represent the intrinsic states of each class. In both cases, we have performed composition through the constructor, receiving the instance of the objects. The next thing we have implemented is the display method, which will receive the extrinsic state, if necessary, and will display information from both states through a console.log.

On the other hand, the Position and Team classes remain exactly the same as in the previous example; they are model classes without further changes.

import { Flyweight } from "./flyweight";

// Flyweight Factory
export abstract class FlyweightFactory<T> {
    protected flyweights: Map<string, Flyweight> = new Map();
    
    public abstract getFlyweight(key: T): Flyweight;

    public listFlyweights(): void {
        console.log(`FlyweightFactory: I have ${this.flyweights.size} flyweights:`);
        for (const [key, _] of this.flyweights) {
            console.log(key);
        }
    }
}

This class defines the two object factories that we will have. The data structure that will store the objects will be a Map that uses a string as the key and any object that implements the Flyweight interface as the value, which will be both Position and Team. The getFlyweight method is defined, which varies slightly depending on whether the factory is for Position or Team objects. This method is where we could improve by applying the template-method pattern, and we leave it as an exercise for you to do.

On the other hand, we see the listFlyweight method, which is exactly the same for both factories since all it does is iterate through the data structure.

import { FlyweightFactory } from "./flyweight.factory";
import { Position } from "./models";
import { PositionFlyweight } from "./position-flyweight";

export class PositionFlyweightFactory extends FlyweightFactory<Position> {

    protected flyweights: Map<string, PositionFlyweight> = new Map();

    public getFlyweight(position: Position): PositionFlyweight {
        const key = `${position.name}_${position.role}`;
        if(this.flyweights.has(key)) {
            console.log(`ConcreteFlyweightFactory: Reusing existing flyweight for Position = ${key}`);
            return this.flyweights.get(key)!;
        }

        this.flyweights.set(key, new PositionFlyweight(position));
        console.log(`PositionFlyweightFactory: Created new flyweight for Position = ${key}`);
        return this.flyweights.get(key)!;
    }
}

import { FlyweightFactory } from "./flyweight.factory";
import { Team } from "./models";
import { TeamFlyweight } from "./team-flyweight";

export class TeamFlyweightFactory extends FlyweightFactory<Team> {

    protected flyweights: Map<string, TeamFlyweight> = new Map();

    public getFlyweight(team: Team): TeamFlyweight {
        const key = `team_${team.name}_coach_${team.coach}`;
        if(this.flyweights.has(key)) {
            console.log(`ConcreteFlyweightFactory: Reusing existing flyweight for Team = ${key}`);
            return this.flyweights.get(key)!;
        }

        this.flyweights.set(key, new TeamFlyweight(team));
        console.log(`PositionFlyweightFactory: Created new flyweight for Team = ${key}`);
        return this.flyweights.get(key)!;
    } 
}

If we look at the concrete implementations of the PositionFlyweightFactory and TeamFlyweightFactory classes, we can see that they are exactly the same, except for the type of object they are working with and the key used to select the object in the data structure. So, we’ll focus on one to explain both. Looking at PositionFlyweight, we see that this method first defines the key, which will be unique for each object and is formed by the values of each object. The next thing we need to do is check if this object exists in the data structure. If it does, we return it without needing to create a new object. But if it doesn’t exist in the data structure, what we do is create the object to store, store it, and finally return the object we just created.

import { IPosition, IStats, ITeam } from "./interfaces";
import { Player, Stats } from "./models";

import { PositionFlyweightFactory } from "./position-flyweight.factory";
import { TeamFlyweightFactory } from "./team-flyweight.factory";

export class SportsSimulator {
    private players: Player[] = [];
    private positionFactory: PositionFlyweightFactory = new PositionFlyweightFactory();
    private teamFactory: TeamFlyweightFactory = new TeamFlyweightFactory();

    public addPlayer(name: string, position: IPosition, team: ITeam, stats: IStats): void {
        const positionFlyweight = this.positionFactory.getFlyweight(position);
        const teamFlyweight = this.teamFactory.getFlyweight(team);
        const statsPlayer = new Stats(stats.goals, stats.assists, stats.passes);
        const player = new Player(name, positionFlyweight, teamFlyweight, statsPlayer);
        this.players.push(player);
    }

    public displayPlayers(): void {
        this.players.forEach(player => player.displayInfo());
    }
}

Finally, we arrive at the SportsSimulator class, which is the database of our players. In this new version, in addition to having the data structure of the players, we need the two factories we just defined. The addPlayer method is where, instead of instantiating all the objects and composing them into the Player, we will use the factories to retrieve or create the objects based on the information. In this way, it will be these classes that decide whether new objects are instantiated or whether they are reused in the system.

import { IPosition, IStats, ITeam } from "./interfaces";

import { SportsSimulator } from "./sports-simulator";

// Client Code
const simulator = new SportsSimulator();

const forward: IPosition = {name: 'Forward', role: 'Attacker'};
const midfielder: IPosition = {name: 'Midfielder', role: 'Support'};
const defender: IPosition = { name: 'Defender', role: 'Defender'};
const goalkeeper: IPosition = {name: 'Goalkeeper', role: 'Goalkeeper'};

const positions = [goalkeeper, defender, midfielder, forward]

const teams: ITeam[] = [
    { name: "New Team", coach: "Roberto Sedinho" },
    { name: "Furano FC", coach: "Koujiro Hyuuga" },
    { name: "Toho Academy", coach: "Kira Hiroto" },
    { name: "Nankatsu SC", coach: "Tsubasa Ozora" },
    { name: "Otomo FC", coach: "Shingo Aoi" },
    { name: "Hirado FC", coach: "Hajime Taki" },
    { name: "Mamoru United", coach: "Taro Misaki" },
    { name: "Meiwa FC", coach: "Jun Misugi" }
];

const captainTsubasaCharacters: string[] = [
    "Tsubasa Ozora",
    "Koujiro Hyuuga",
    "Genzo Wakabayashi",
    "Taro Misaki",
    "Shingo Aoi",
    "Hikaru Matsuyama",
    "Jun Misugi",
    "Ken Wakashimazu",
    "Kazuo Tachibana",
    "Masao Tachibana",
    "Ryo Ishizaki",
    "Kojiro Hyuga",
    "Teppei Kisugi",
    "Hiroshi Jito",
    "Shun Nitta",
    "Mamoru Izawa",
    "Hanji Urabe",
    "Shingo Takasugi",
    "Mitsuru Sano",
    "Makoto Soda"
];


for(let i = 0; i < 25*teams.length -1; i++){
    const team = teams[i % teams.length];

    const position = positions[i % positions.length];
    const playerName = captainTsubasaCharacters[i % captainTsubasaCharacters.length];
    const stats: IStats = {
        goals: Math.floor(Math.random() * 20),
        assists: Math.floor(Math.random() * 20),
        passes: Math.floor(Math.random() * 20),
    };

    simulator.addPlayer(playerName, position, team, stats);
}

simulator.displayPlayers();

Finally, the client that uses our SportsSimulator class is completely transparent and remains exactly the same, creating the data or receiving it from some data source, and sending it to SportsSimulator. But now, instead of having an explosion of objects consuming hardware resources, many of these objects will be reused, making the software lighter and able to continue providing service. In other words, we have achieved an optimization of RAM memory by making the objects lighter.

Flyweight Pattern: Relationship with Other Patterns

The Flyweight pattern has connections with several other design patterns, as it can complement and enhance their functionality. Some of the most relevant relationships include:

1. Singleton Pattern: The Singleton pattern can be used in conjunction with the Flyweight pattern to ensure that only one instance of the Flyweight Factory exists throughout the application. This ensures centralized management of Flyweight objects and prevents unnecessary creation of multiple factories.
2. Factory Method Pattern: The implementation of the Flyweight Factory can leverage the Factory Method pattern to allow flexible and decoupled creation of Flyweight objects. This facilitates the creation and management of Flyweight object instances as needed in different parts of the system.
3. Composite Pattern: The Composite pattern can be used in combination with the Flyweight pattern to represent hierarchical structures where some objects can be shared among multiple components. By using the Flyweight pattern for shared objects, memory consumption is significantly reduced, and system efficiency is improved.
4. Proxy Pattern: The Proxy pattern can serve as a wrapper around a Flyweight object, allowing additional control over object access or lifecycle management. This can be useful when more granular control over access to SharedFlyweight objects is needed or when additional tasks need to be performed before or after accessing the object.

By leveraging these relationships with other patterns, the Flyweight pattern can enhance the efficiency, scalability, and maintainability of a system while optimizing resource usage and promoting a clearer and more modular code structure.

Differences and Similarities with Other Patterns: Singleton and Prototype

Let’s examine the similarities and differences between the Singleton and Prototype design patterns since the Flyweight pattern is often confused with these two design patterns.

Singleton Pattern: Differences

1. The Singleton pattern is used to ensure that a class has only one instance and provides a global access point to that instance, while the Flyweight pattern is used to efficiently share a large number of objects.
2. In the Singleton pattern, the emphasis is on having a single instance of a class, while in the Flyweight pattern, the emphasis is on efficiently sharing intrinsic states among multiple similar objects.

Singleton Pattern: Similarities

1. Both patterns are related to efficient object management and resource optimization.
2. Both patterns can be used together to optimize the performance and efficiency of a system.

Prototype Pattern: Differences

• The Prototype pattern is used to create new objects by duplicating an existing prototype, while the Flyweight pattern is used to share existing objects and minimize resource usage.
• In the Prototype pattern, each instance can have its own unique state, while in the Flyweight pattern, part of the state can be shared among multiple instances.

Prototype Pattern: Similarities

• Both patterns are related to efficient object creation and resource optimization.
• Both patterns can be used to reduce the overhead of object creation and improve system performance.

Although the Flyweight pattern shares some similarities with the Singleton and Prototype patterns, it is important to understand their fundamental differences and how they can be used complementary to address different design problems.

Conclusions

The Flyweight pattern provides an efficient and elegant solution for systems that need to manage a large number of similar objects. By sharing common parts of objects among multiple instances, significant resource optimization and system performance improvement are achieved.

The most important thing about the Flyweight pattern is not its specific implementation, but the ability to recognize the problem that this pattern can solve and when it can be applied. The specific implementation is not that important, as it will vary depending on the programming language used.

See this GitHub repo for the full code.

There are 23 classic design patterns described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Mediator pattern works and when it should be applied.

Mediator: Basic idea

First, let’s see the definition provided by the Gang of Four book:

Define an object that encapsulates how a set of objects interact. The mediator pattern promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Next, let’s take a look at the UML class diagram for this pattern to understand each of its elements.

The Mediator pattern typically includes the following main elements:

• Mediator: Defines the interface for communication with Colleague objects.
• Concrete Mediator: Implements the Mediator interface and coordinates communication between Colleague objects.
• Colleague: Defines the interface for communication with other colleagues through the mediator.
• Concrete Colleague: Implements the Colleague interface and communicates its needs to the mediator, reacting to messages from the mediator.

Mediator Pattern: When to Use It

The Mediator pattern is a good solution when we find ourselves with a system in which a set of objects communicate in a complex and direct way with each other, resulting in high coupling between them. Here are some common situations where using the Mediator pattern can be beneficial:

1. Complex communication between multiple objects: As we have said, when we have several objects that need to communicate with each other in a complex and direct way, this can be difficult to understand and maintain. The Mediator pattern centralizes this complex communication into a single object, thus simplifying the communication flow and reducing coupling between objects.

2. Reducing coupling: If you want to reduce coupling between the components of your system, the Mediator pattern can help. By centralizing communication between objects through a mediator, direct dependencies between objects are eliminated, making it easier to modify and maintain code.

3. Facilitating component reusability: The Mediator pattern promotes the reusability of individual components by decoupling them from their interactions with other components. This allows objects to be more independent and therefore easier to reuse in different contexts or systems.

In summary, the Mediator pattern is useful in situations where it is necessary to reduce coupling between objects, simplify communication between them, and facilitate the maintenance and evolution of code in complex systems.

Let’s now move on to see examples of how to apply this pattern.

Mediator Pattern: Examples

In this section, we will illustrate the Mediator pattern with two examples:

1. Basic Structure of the Mediator Pattern: In this example, we will translate the theoretical UML diagram into TypeScript code to identify each of the classes involved in the pattern.
2. IoT Device Control System: In an Internet of Things (IoT) system where devices communicate directly with each other to coordinate their actions. If each device depends directly on other devices for communication, the system can become difficult to scale and maintain.

Example 1: Basic Structure of the Mediator Pattern

As always, the starting point is the UML class diagram. This UML class diagram is the same as the one we explained at the beginning of the post, and to lighten the post we will not explain it again as such. But we will start to see its implementation step by step.

Let’s start with the Mediator interface. This interface defines the contract that any mediator in the system must follow. In this case, it only has one method that we have called notify which receives the event sender (sender) and the event itself (event). This method is implemented by concrete mediators to handle communication between colleagues.

import { Colleague } from "./colleague";

export interface Mediator {
    notify(sender: Colleague, event: string): void;
}

The next class is the concrete mediator. This class implements the Mediator interface. It has references to the colleagues with which it will interact. In the notify method, the mediator receives an event from a colleague and decides how to handle it based on the sender. In our case, the solution has been modeled using a switch control structure in which, depending on the colleague, we invoke a request handler. In this example, we only display messages on the screen to know that the notification has arrived correctly.

import { Colleague } from "./colleague";
import { Colleague1 } from "./colleague1";
import { Colleague2 } from "./colleague2";
import { Mediator } from "./mediator";

export class ConcreteMediator implements Mediator {
    private colleague1: Colleague1;
    private colleague2: Colleague2;

  
    constructor(colleague1: Colleague1, colleague2: Colleague2) {
      this.colleague1 = colleague1;
      this.colleague2 = colleague2;
    }
  
    notify(sender: Colleague, event: string): void {
        switch(sender){
            case this.colleague1: this.handleColleague1(event); break;
            case this.colleague2: this.handleColleague2(event); break;
            default: console.log("Unknown sender");
        }

    }
    private handleColleague1(event){
        console.log("Event received by ConcreteMediator from Colleague1: ", event);
        console.log("implements colleague1 logic");
        console.log("-----------------");
    }

    private handleColleague2(event){
        console.log("Event received by ConcreteMediator from Colleague1: ", event);
        console.log("implements colleague1 logic");
        console.log("-----------------");
    }
}

The next thing would be to define the colleague interface, which is the contract that all colleagues in the system must follow. In this case, they have two methods: setMediator, to set the mediator they belong to, and action, to perform an action that can generate an event.

import { Mediator } from "./mediator";

export interface Colleague {
    setMediator(mediator: Mediator): void;
    action(): void;
}

What remains to be seen of the Mediator pattern would be the colleagues that implement this interface. In this case, they receive the mediator dependency through the constructor, and it is stored in a private attribute of the mediator type. This reference is very useful for communicating with the mediator when an event occurs, this is done in the action method, where we can see how it is being notified that an action has been performed that we want to be managed by the mediator through the notify method. This method is sent as a parameter the class itself that sends the request and the message or parameter that we want to be managed from the mediator.

import { Colleague } from "./colleague";
import { Mediator } from "./mediator";

export class Colleague1 implements Colleague {
    private mediator: Mediator;
  
    setMediator(mediator: Mediator): void {
      this.mediator = mediator;
    }
  
    action(): void {
      this.mediator.notify(this, "Event from Colleague1");
    }
}

export class Colleague2 implements Colleague {
    private mediator: Mediator;
  
    setMediator(mediator: Mediator): void {
      this.mediator = mediator;
    }
  
    action(): void {
      this.mediator.notify(this, "Event from Colleague2");
    }
}

At this point, we can think that the mediator pattern could use another pattern to communicate both to colleagues and to the mediator in a more reactive way, and this would be using the Observer pattern, which we have already talked about in other articles and you can read here. We leave you as a task, once you have internalized the mediator pattern, how to apply the observer pattern together with it.

To conclude, we would have to see how this pattern is used from the client class.

import { Colleague1 } from "./colleague1";
import { Colleague2 } from "./colleague2";
import { ConcreteMediator } from "./concrete-mediator";

const colleague1 = new Colleague1();
const colleague2 = new Colleague2();

const mediator = new ConcreteMediator(colleague1, colleague2);

colleague1.setMediator(mediator);
colleague2.setMediator(mediator);

colleague1.action();
colleague2.action();

In this class, the colleagues that interact with each other are instantiated. We relate the colleagues through the mediator, which is the one that will perform the mediation tasks between them.

On the other hand, we pass the mediator as a parameter to each colleague so that communication between the colleagues and the mediator can be achieved, that is, that the colleagues notify or warn that an event has occurred to the mediator.

And finally, each colleague will independently execute its action, which will be notified to the mediator and it will perform the different mediation tasks.

In this way we have decoupled the different colleagues from knowing each other, allowing new colleagues to be created without the need to know each other.

Now let’s move on to a different example, where we will start by seeing the lack of use of this pattern and then the solution with the pattern.

Example 2: IoT Device Control System without Mediator Pattern

In this example, we will create an IoT device control system where devices communicate directly with each other to coordinate their actions. Without the Mediator pattern, the code could be very coupled since devices communicate directly with each other.

If we look at the UML class diagram, we first find the abstract class IoTDevice that defines the methods that all IoT devices must have. In our case, all devices will have an attribute that corresponds to the id, and then methods to communicate with other devices such as sending and receiving messages. On the other hand, we see that the classes that extend this abstract class implement the methods that are defined for both sensors and actuators. However, to have some difference, we have included the receiveControlSignal method in the Actuator class as an extension of it.

It is important to note that devices communicate with other devices through the arguments of the methods they implement, which is where the reference to the colleagues they want to interact with is being sent.

Finally, we will have the application client class that will make use of all the devices with which it wants to interact.

Let’s see the implementation of this first solution that does NOT use the Mediator pattern.

The first step is to define the abstract class IoTDevice. This class defines the common methods for all devices, the sendMessage and receiveMessage methods that simply display the information they receive on the screen. Right here, we could have a very different logic but we have simplified it to show how the devices communicate with each other. On the other hand, the sendMeasurement method has some logic in that it can only operate if the receiver is an Actuator, and the specific business logic is implemented there.

abstract class IoTDevice {
    constructor(public id: string) {}
  
    // Method to send a message to another device
    sendMessage(receiver: IoTDevice, message: string): void {
      console.log(`[${this.id}] Sending message to ${receiver.id}: ${message}`);
      // Logic to send the message to the receiver
      receiver.receiveMessage(this, message);
    }
  
    // Method to receive a message from another device
    receiveMessage(sender: IoTDevice, message: string): void {
      console.log(`[${this.id}] Message received from ${sender.id}: ${message}`);
      // Logic to process the received message
    }
      
    // Method to send measurement data to another device
    sendMeasurement(receiver: IoTDevice, data: any): void {
      console.log(`[${this.id}] Sending measurement data to ${receiver.id}: ${JSON.stringify(data)}`);
      // Logic to send the data to the receiver
      if (!(receiver instanceof Actuator)) {
        return console.log("Error: Measurement data can only be sent to an Actuator.");
      } 
      receiver.receiveMeasurement(this, data);
    }

      
    // Method to receive measurement data from a sensor
    receiveMeasurement(sender: IoTDevice, data: any): void {
      console.log(`[${this.id}] Measurement data received from ${sender.id}: ${JSON.stringify(data)}`);
      // Logic to process the received measurement data
    }
}

The concrete classes that extend the abstract class would be the colleagues of the pattern. Specifically, we would have two types of devices: sensors and actuators.

export class Sensor extends IoTDevice {
    constructor(id: string) {
      super(id);
    }
}
  
export class Actuator extends IoTDevice {
    constructor(id: string) {
      super(id);
    }
    // Method to receive a control signal from another device
    receiveControlSignal(sender: IoTDevice, signal: string): void {
       console.log(`[${this.id}] Receiving control signal from ${sender.id}: ${signal}`);
       // Logic to process the received control signal
   }
}

We can see how these classes extend the abstract class. On the one hand, the Sensor class, which does not have any extra particularity and therefore is still without extended methods, and on the other hand the Actuator class, which has its own method, which we implement in its concrete class.

Finally, we would have to see the code of the client that makes use of all these classes. The first thing we have to do is create all the devices. To do this, we create two sensors and one actuator. These are our colleagues who want to interact with each other.

const sensor1 = new Sensor("Sensor1");
const sensor2 = new Sensor("Sensor2");
const actuator1 = new Actuator("Actuator1");
  
// Example interaction between devices
sensor1.sendMessage(sensor2, "How are you?");
sensor2.sendMeasurement(actuator1, { temperature: 25, humidity: 60 });
actuator1.receiveControlSignal(sensor2, "Turn off");

And then we see the communication between them, how first sensor1 has to send sensor2 as an argument to send it a message. On the other hand, sensor2s has to send actuator1a and the configuration parameters as arguments so that it receives them.

Finally, the actuator has to send sensor2 and the information as arguments. Here, the coupling between the different colleagues is clearly visible, since they are going to talk to each other directly from their implementations, in this case in the IoTDevice abstract class, which is the one that manages all the work to be done.

Let’s move on to decoupling this code right now.

Example 2: IoT Device Control System Using Mediator Pattern

The problems that appear in the solution without the Mediator pattern are the following:

• High Cohesion: The communication logic is coupled between objects and any change in the logic affects different classes.
• Scalability and maintainability: Adding new objects implies modifying other classes to fit. In addition, there is greater difficulty in understanding and modifying the communication flow between objects.
• Tight coupling: There is a strong dependency between the objects involved in the communication, which makes it difficult to modify or reuse them independently.

Therefore, in this example, we clearly see the need for the Mediator pattern, where we could include an element that would be the connection point between the different colleagues.

Let’s start by seeing how the UML class diagram evolves.

We start by seeing that the abstract class has not changed in the definition of the methods that are defined in it a priori. But there is a very important change, now the devices do not communicate with other devices, but rather a request is made about which device you want to communicate with, this parameter could be a unique identifier to find it, in our case to simplify we are going to use a string to define the device id.

This subtle but very important change. In addition, we now find that we will have an attribute called mediator which will be responsible for performing the tasks where the devices interact with each other. Finally, the definition of the Sensor and Actuator classes now we have to reference this mediator attribute through the constructor of the classes. We could have assigned the mediator through the constructor or with a setMediator accessor method, that is already up to the developer.

On the other hand of the class diagram we can see that we have an interface called IoTMediator that specifies the necessary methods that all concrete mediators must implement. In our example we will only have one concrete mediator that we have called ConcreteMediatorIoT. This concrete mediator is responsible for coordinating the different devices.

Well, let’s go step by step, the implementation and how it has changed compared to the previous example to achieve decouple the communication between the different devices.

Let’s start with the code of the abstract class IoTDevice which models the common logic of all devices.

import { IoTMediator } from "./iot-mediator";

export abstract class IoTDevice {
    constructor(public id: string, protected mediator: IoTMediator) {
      mediator.registerDevice(this);
    }
  
    // Method to send a message to another device
    sendMessage(receiverId: string, message: string): void {
      this.mediator.sendMessage(this, receiverId, message);
    }
  
    // Method to send measurement data to another device
    sendMeasurement(receiverId: string, data: any): void {
      this.mediator.sendMeasurement(this, receiverId, data);
    }
  
    // Method to receive a message from another device
    receiveMessage(senderId: string, message: string): void {
      this.mediator.receiveMessage(this, senderId, message);
    }
  
    // Method to receive measurement data from another device
    receiveMeasurement(senderId: string, data: any): void {
      this.mediator.receiveMeasurement(this, senderId, data);
        // Logic to process the received measurement data
   }
}

If we look at the constructor we see that we create a new device from its identifier and a mediator. When the device is instantiated, what is done is to register the device with the mediator. This is done through the registerDevice method which receives as an argument the instance of the Device class that has just been created, important, this method will be executed in the concrete device classes, that is, in the Sensor or Actuator class. In our case, we have merged in the constructor methods that could have been divided into methods such as the accessor method that would register the concrete mediator to the device, and another later that would register the device with the mediator. However, to simplify the code since the objective of the pattern is another, we have simplified it into a single method.

The rest of the common methods that all devices have are very simple, since we are delegating the responsibility to the mediator, through concrete mediator methods. The mediator only needs to know which device wants to perform the operation, it does this through the first argument with the reserved word this, and then the specific parameters of the operation that you want to perform. It is important to note that the interaction logic between colleagues has been delegated to the mediator.

The next thing is to see the specific devices, the Sensor class does not have anything extra since we have simplified it as much as possible and does not have any extra behavior. So we can see that the constructor simply invokes the class it extends.

import { IoTDevice } from "./iot-device";
import { IoTMediator } from "./iot-mediator";

export class Sensor extends IoTDevice {
    constructor(id: string, mediator: IoTMediator) {
      super(id, mediator);
    }
}

On the other hand, the Actuator  class includes an extra method to the base class, which is receiveControlSignal, but if we look closely, we are doing exactly the same, we are delegating the communication responsibility to the mediator class which is responsible for putting the devices in contact.

import { IoTDevice } from "./iot-device";
import { IoTMediator } from "./iot-mediator";

export class Actuator extends IoTDevice {
    constructor(id: string, mediator: IoTMediator) {
      super(id, mediator);
    }
  
    // Method to receive a control signal from another device
    receiveControlSignal(senderId: string, signal: string): void {
      this.mediator.receiveControlSignal(this, senderId, signal);
    }
}

Now let’s see the concrete part of the pattern, the part corresponding to the mediators.

Let’s start by seeing the IoTMediator interface where you can see all the methods that the different colleagues use. To simplify we have included the method that we would only have in the Actuator. If we wanted to do it even better, instead of having a single concrete mediator, we could have two concrete mediators, one for the sensors and one for the actuators. However, we say the same again, we want to get the idea of how the mediator pattern works, once we have it, we can apply other different techniques or other patterns that allow us to continue decoupling the different parts of the code.

import { IoTDevice } from "./iot-device";

export interface IoTMediator {
    registerDevice(device: IoTDevice): void;
    sendMessage(sender: IoTDevice, receiverId: string, message: string): void;
    sendMeasurement(sender: IoTDevice, receiverId: string, data: any): void;
    receiveMessage(receiver: IoTDevice, senderId: string, message: string): void;
    receiveMeasurement(receiver: IoTDevice, senderId: string, data: any): void;
    receiveControlSignal(receiver: IoTDevice, senderId: string, signal: string): void;
}

The business logic of communication between the different devices is in the ConcreteIoTMediator class. In this class we have a Map of devices as an attribute. In this way, we have all the devices that want to interact with each other. To add devices to this data structure, we have designed the registerDevice method, which receives any device, both sensors and actuators, and is added to the Map.

We have prepared a private findOrError method that will search the Map for the device if it exists based on a device id and return it or if it does not exist, we will return an error that the device is not registered.

And now if we look at the sendMessage method, here we can see how the mediator is the one that coordinates the devices. The first thing that is done is to retrieve the receiver that is going to receive the message, and we can see how we invoke the receiveMessage method of the receiver once the message has been received from the sender. This device method will return to the mediator, and it will be the receiveMessage method that we have implemented in this class. The receiveMessage method is quite simple since it only performs a result trace to verify that all the communication between these devices is correct.

On the other hand, we see the sendMeasurement method which includes some logic, in which we explicitly check that the receiver must be of the Actuator class, otherwise, we return an error.

import { Actuator } from "./actuator";
import { IoTDevice } from "./iot-device";
import { IoTMediator } from "./iot-mediator";

export class ConcreteIoTMediator implements IoTMediator {
    private devices: Map<string, IoTDevice> = new Map();
  
    registerDevice(device: IoTDevice): void {
      this.devices.set(device.id, device);
    }

    private findOrError(id: string): IoTDevice {
      const device = this.devices.get(id);
      if (!device) {
        throw new Error(`Device ${id} not found.`);
      }
      return device;
    }
  
    sendMessage(sender: IoTDevice, receiverId: string, message: string): void {
      const receiver = this.findOrError(receiverId);

      console.log(`[${sender.id}] Sending message to ${receiverId}: ${message}`);
      receiver.receiveMessage(sender.id, message);   
    }
  
    sendMeasurement(sender: IoTDevice, receiverId: string, data: any): void {
      const receiver = this.findOrError(receiverId);
 
      console.log(`[${sender.id}] Sending measurement data to ${receiverId}: ${JSON.stringify(data)}`);
      // Logic to send the data to the receiver
      if (!(receiver instanceof Actuator)) {
        return console.log("Error: Measurement data can only be sent to an Actuator.");
      } 
      receiver.receiveMeasurement(sender.id, data);
    }

    receiveMessage(receiver: IoTDevice, senderId: string, message: string): void {
      const sender = this.findOrError(senderId);

      console.log(`[${receiver.id}] Message received from ${sender.id}: ${message}`);
      // Logic to process the received message
    }

    receiveMeasurement(receiver: IoTDevice, senderId: string, data: any): void {
      const sender = this.findOrError(senderId);
      console.log(`[${receiver.id}] Measurement received from ${sender.id}: ${JSON.stringify(data)}`);
      // Logic to process the received message
    }

    receiveControlSignal(receiver: IoTDevice, senderId: string, signal: string): void {
      const sender = this.findOrError(senderId);
  
      console.log(`[${receiver.id}] Receiving control signal from ${sender.id}: ${signal}`);
        // Logic to process the received control signal
  }
}

In this way, the mediators are the ones that implement the communication between the devices, or colleagues, and of course, we have to be careful not to make the mediators into God classes, since this would be an anti-pattern that we have to fix in a next phase of software development.

The client that makes use of the pattern, we must have a first phase of instantiation of all the necessary classes, mediator and different devices. Then each device makes use of its communication interface. For example, sensor1 uses the sendMessage method, or sensor2 the sendMeasurement method. Important, now the devices are not communicating directly, but an identifier is being specified with which to communicate.

import { Actuator } from "./actuator";
import { ConcreteIoTMediator } from "./concrete-iot-mediator";
import { Sensor } from "./sensor";
// Create the Mediator
const mediator = new ConcreteIoTMediator();

// Create IoT devices
const sensor1 = new Sensor("Sensor1", mediator);
const sensor2 = new Sensor("Sensor2", mediator);
const actuator1 = new Actuator("Actuator1", mediator);

// Example interaction between devices
sensor1.sendMessage("Sensor2", "How are you?");
sensor2.sendMeasurement("Actuator1", { temperature: 25, humidity: 60 });
actuator1.receiveControlSignal("Sensor2", "Turn off");

sensor1.sendMessage("Invalid-sensor", "How are you?");

And with this, we conclude by seeing the example, and we will see how this pattern is related to other design patterns.

Mediator Pattern: Relationship with other patterns

The Mediator pattern can be related to several other design patterns, as it is often used in conjunction with them to solve complex software design problems. Some of the related patterns include:

1. Observer Pattern: The Observer pattern is often used together with the Mediator pattern to allow objects to subscribe to and receive notifications about changes in other objects. This can help to keep objects loosely coupled and facilitate two-way communication.

2. Singleton Pattern: A mediator is sometimes implemented as a singleton to ensure that there is only one instance of the mediator in the system. This can be useful to ensure that all objects in the system communicate through the same centralized mediator.

3. Command Pattern: The Command pattern can be used together with the Mediator pattern to encapsulate requests as objects, allowing clients to parameterize other objects with requests, rather than sending requests directly. This can make it easier to implement systems with logging and undo capabilities.

4. Factory Method Pattern: The Factory Method pattern is often used to create instances of objects that interact through a mediator. This can help to hide the complexity of object creation and ensure that the correct implementations of objects are used in the system.

5. State Pattern: The State pattern is sometimes used together with the Mediator pattern to allow an object to change its behavior when its internal state changes. The mediator may be responsible for changing the state of an object and notifying other objects about the state change.

These are just a few examples of patterns that may be related to the Mediator pattern. Depending on the context and system requirements, other pattern combinations may emerge to address different design issues.

Conclusions

In general, the Mediator pattern is a valuable tool for designing systems with complex communication between objects, especially when looking for:

• Low coupling: Collaborating objects do not know each other directly, but communicate through the mediator. This reduces dependencies between objects and makes them easier to reuse and maintain.
• Centralization of communication logic: The logic of how objects interact is encapsulated in the mediator, making it easier to understand and modify.
• Communication flexibility: The mediator can be implemented in different ways to adapt to the specific needs of the system.
• Code reuse: The mediator can be reused in different parts of the system, reducing the amount of duplicate code.

However, the use of the Mediator pattern also has some disadvantages:

• Increased complexity: The system design may be more complex, since a new object (the mediator) must be added to manage communication.
• Potential performance loss: Indirect communication through the mediator may be slightly slower than direct communication between objects.

The most important thing about the Mediator pattern is not its specific implementation, but the ability to recognize the problem that this pattern can solve and when it can be applied. The specific implementation is not that important, as it will vary depending on the programming language used.

See this GitHub repo for the full code.

There are 23 classic design patterns described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Bridge pattern works and when it should be applied.

Bridge: Basic Idea

According to Wikipedia, the Bridge pattern is a structural software design pattern that separates an abstraction from its implementation, so that both can vary independently. This pattern promotes composition over inheritance by decoupling the abstraction from its implementation. The main idea is to have two independent class hierarchies, one for the abstraction and another for the implementation, and then connect them together using a bridge.

On the other hand, the definition provided by the original book is as follows:

Separate an abstraction from its implementation so that both can vary independently.

In many cases, we encounter situations where we want the flexibility to change both the abstraction and the implementation of an object independently. For example, in a drawing system, we may have different shapes (abstractions) that can be drawn in different ways (implementations). This is where the Bridge design pattern can help us write more flexible and maintainable code.

Next, let’s take a look at the UML class diagram of this pattern to understand each of the elements that interact in it.

These are the classes that comprise this pattern:

• Abstraction: This is the interface of interest to clients. It maintains a reference to an Implementor object that defines the abstract interface for the implementation classes.
• RefinedAbstraction: This class extends the interface defined by Abstraction. It can add additional methods or functionality specific to the abstraction.
• Implementor: This defines the interface for the implementation classes. It does not have to correspond directly to Abstraction’s interface.
• ConcreteImplementorA and ConcreteImplementorB: These are the subclasses that implement the Implementor interface. Each ConcreteImplementor provides a specific implementation of the interface defined by Implementor.

By separating the abstraction from its implementation and allowing them to vary independently, the Bridge pattern enables greater flexibility and extensibility in our codebase.

Bridge Pattern: When to Use It

The Bridge design pattern is particularly useful in the following scenarios:

1. You want to separate an abstraction from its implementation: The Bridge pattern is ideal when you need to have the flexibility to vary both the abstraction and the implementation independently. By decoupling these two aspects, you can make changes to one without affecting the other.
2. You have multiple hierarchies that need to be extended independently: When you have two or more orthogonal class hierarchies that need to be extended independently, the Bridge pattern provides an elegant solution. It allows you to manage each hierarchy separately and then connect them as needed through the bridge.
3. You want to avoid a proliferation of subclasses: Without the Bridge pattern, you might end up with a large number of subclasses, each combining different abstractions with different implementations. This can lead to a complex and rigid class hierarchy. By using the Bridge pattern, you can avoid this proliferation of subclasses and keep your codebase more manageable.

In summary, the Bridge pattern is beneficial when you need to decouple abstraction from implementation, manage multiple hierarchies independently, and avoid a proliferation of subclasses.

Bridge Pattern: Advantages and Disadvantages

The Bridge pattern offers several advantages, which can be summarized as follows:

Advantages

1. Decoupling of abstraction and implementation: The Bridge pattern promotes decoupling by separating an abstraction from its implementation. This allows changes to one side of the bridge to occur without affecting the other side, thus enhancing flexibility and maintainability.
2. Enhanced extensibility: By allowing both the abstraction and implementation to vary independently, the Bridge pattern facilitates easier extension of the system. New abstractions or implementations can be introduced without requiring modifications to existing code, thereby adhering to the Open-Closed Principle.
3. Reduced Class Proliferation: The Bridge pattern helps prevent class explosion by avoiding the creation of a large number of subclasses to handle different combinations of abstractions and implementations. Instead, it promotes a more modular and manageable class structure.

However, like most design patterns, the Bridge pattern also comes with its drawbacks.

Disadvantages

1. Increased complexity: Implementing the Bridge pattern may introduce additional complexity to the codebase, as it involves defining multiple interfaces and classes to manage the separation between abstraction and implementation.
2. Higher initial overhead: Initially, applying the Bridge pattern may require more effort to set up the necessary abstractions, implementations, and bridges. This upfront cost may deter developers from using the pattern in simpler scenarios.

In summary, while the Bridge pattern offers advantages such as decoupling and extensibility, it also requires careful consideration of the trade-offs, particularly regarding code complexity and initial overhead.

Bridge Pattern Examples

Next, we will illustrate the Bridge pattern with two examples:

1. Basic Structure of the Bridge Pattern: In this example, we will translate the theoretical UML diagram into TypeScript code to identify each of the classes involved in the pattern.
2. Multiplatform Messaging System: Let’s consider a messaging system that needs to function on both mobile devices and desktop computers. Without the Bridge pattern, the code could become tightly coupled to specific platforms, requiring significant code rewriting whenever a platform change is needed. We will first demonstrate the code without applying the Bridge pattern, and then we will show how applying the pattern can help decouple the code from platform-specific implementations.

Example 1: Basic Structure of the Bridge Pattern

First of all, we can see the UML class diagram of the implementation using the Bridge design pattern.

So let’s start looking at its implementation in code. The first element of this design pattern is the Implementor interface, where the different operations that we want all concrete implementations to have are defined.

export interface Implementor {
	operationImplementation(): void;
 }

The next step would be to see the concrete classes that satisfy the concrete interface; in our example, we are only defining a single method for our classes. This first branch focuses on the concrete implementations, not on the abstractions.

import { Implementor } from './implementor';

export class ConcreteImplementorA implements Implementor {
    operationImplementation(): void {
        console.log("ConcreteImplementorA operation implementation.");
    }
}

export class ConcreteImplementorB implements Implementor {
    operationImplementation(): void {
        console.log("ConcreteImplementorB operation implementation.");
    }
}

The second part of the UML class diagram shows the part corresponding to the abstractions. The Abstraction class is an abstract class and therefore cannot be instantiated, but the key here is that it has an attribute that must adhere to the Implementor interface. In this case, we have achieved composition through the constructor of the Abstraction class; of course, we could have done it through an accessor method. The other key point of this abstraction class is that there is an abstract method, in our case operation, which will be implemented in a class that extends this abstract class.

import { Implementor } from './implementor';

export abstract class Abstraction {
    protected implementor: Implementor;

    constructor(implementor: Implementor) {
        this.implementor = implementor;
    }

    abstract operation(): void;
}

If we take a look at the last class of the refine abstraction design pattern, we see that it extends the abstraction class, and there we have the concrete implementation of the operation method, which uses an instance of a class that satisfies the Implementor interface, which could be either concreteImplementorA or concreteImplementorB.

import { Abstraction } from './abstraction';

export class RefinedAbstraction extends Abstraction {
    operation(): void {
        console.log('RefinedAbstraction: operation');
        this.implementor.operationImplementation();
    }
}

Finally, let’s take a look at the class that utilizes the bridge pattern.

The client class instantiates both concreteImplementor classes, which are then used to create an instance of the refineAbstraction class, with the desired concreteImplementor passed as a parameter. Ultimately, it is the abstraction class that invokes the refined abstraction.

import { Abstraction } from './abstraction';
import { ConcreteImplementorA } from './concrete-implementorA';
import { ConcreteImplementorB } from './concrete-implementorB';
import { RefinedAbstraction } from './refine-abstraction';

class Client {
    static main(): void {
        const implementorA = new ConcreteImplementorA();
        const implementorB = new ConcreteImplementorB();

        let abstraction: Abstraction = new RefinedAbstraction(implementorA);
        abstraction.operation();

        abstraction = new RefinedAbstraction(implementorB);
        abstraction.operation();
    }
}
Client.main();

In this way, we have decoupled the implementation from the abstraction.

If anyone has noticed that the structure of this design pattern resembles surprisingly the template-method and strategy patterns, we will leave a comparison of these three patterns at the end of the post. Now let’s move on to a different example, where we will start by observing the lack of use of this pattern and then the solution with the pattern.

Example 2: Multiplatform Messaging System — Problem

Let’s think about a messaging system that needs to work on both mobile and desktop devices. Without the Bridge pattern, the code could be tightly coupled to specific platforms, making any changes to the platform require significant code rewriting.

If we look at the UML class diagram, we find two different classes that have two different implementations for each messaging system. On one side, we have the MobileMessaging class, and on the other side, DesktopMessaging. Both classes implement methods for sending and receiving messages. In the case of the DesktopMessaging class, the methods are named sendMessageFromDesktop and receiveMessageOnDesktop, while for the MobileMessaging class, the methods are named sendMessageFromMobile and receiveMessageOnMobile.

export class DesktopMessaging {
    sendMessageFromDesktop(message: string): void {
        console.log("Sending message from a desktop: " + message);
    }

    receiveMessageOnDesktop(): string {
        return "Message received on a desktop.";
    }
}

export class MobileMessaging {
    sendMessageFromMobile(message: string): void {
        console.log("Sending message from a mobile device: " + message);
    }

    receiveMessageOnMobile(): string {
        return "Message received on a mobile device.";
    }
}

On the other hand, we have a client that directly uses both classes, instantiating them and causing direct coupling to these two classes. If there is any change in them now, we don’t have a common interface acting as a contract between the classes, leading to direct coupling. Let’s see the implementation.

The code for these classes is quite simple, as we can see. Both classes have the two methods that either display a message via console.log or return a string, nothing more.

import { DesktopMessaging } from "./desktop-messaging";
import { MobileMessaging } from "./mobile-messaging";

class Client {
    static main(): void {
        const mobileMessaging = new MobileMessaging();
        mobileMessaging.sendMessageFromMobile("Hello from Mobile!");
        console.log(mobileMessaging.receiveMessageOnMobile());

        const desktopMessaging = new DesktopMessaging();
        desktopMessaging.sendMessageFromDesktop("Hello from Desktop!");
        console.log(desktopMessaging.receiveMessageOnDesktop());
    }
}

Client.main();

In the Client class, we can see how we have to instantiate two different objects of the MobileMessaging and DesktopMessaging classes. Then, we use the methods specific to each of these classes. In one case, sendMessageFromMobile, and in the other, sendMessageFromDesktop. Here, we detect, on one hand, the lack of a common interface that could unify these methods, but also, we notice that if there is a change in these methods, the code is tightly coupled, and the client must be completely redefined. Furthermore, the example also ends up using the receiveMessageOnMobile and receiveMessageOnDesktop methods, which have the same problem as the previous methods. Additionally, in case the classes are extended through inherited classes, we will encounter an explosion of unnecessary classes.

Next, we will see the solution using the Bridge design pattern.

Example 2: Multiplatform Messaging System — Solution

As we’ve discussed, the problems that arise in this solution without the Bridge design pattern are as follows:

1. Code duplication: Each class has very similar methods, leading to code duplication.
2. High cohesion: The messaging logic is tightly coupled to the specific platform, making it difficult to make changes to the messaging logic without affecting the specific platform implementation.
3. Scalability and maintainability: Adding support for new platforms or changing messaging behavior requires extensive modifications or code duplication.

In this example, we clearly see the need for the Bridge pattern, where we can separate the abstraction meaning the messaging operations, from its implementation which would be the specific platform details, allowing both to vary independently. In the next step, let’s refactor this code to implement the Bridge pattern and address these issues.

Let’s start by looking at how the UML class diagram evolves.

First, we see in the diagram the MessageSender interface that we needed in the code without the pattern. This interface defines the methods sendMessage and receiveMessage. This interface is common to all concrete classes.

In this case, the concrete implementations for the desktop and mobile platforms are implemented in the DesktopSender and MobileSender classes. We have the concrete implementations on this side, and now we need to see the abstractions.

If we look at the MessagingService class, it is an abstract class that includes an object that satisfies the MessageSender interface, which can be either desktop or mobile, or even if there were a new platform like XBOXSender, it would still work as long as it adheres to the MessageSender interface. Because this is an abstract class, we need to have a class that extends it and implements the abstract methods of this class, namely, the send and receive methods.

The AdvancedMessaging class is responsible for implementing the send and receive methods. Of course, in our case, it will make use of the sender instance. Finally, the client will only use the AdvancedMessaging class and the specific platform it needs. Let’s see this solution through the source code.

Let’s see this solution through the source code.

export interface MessageSender {
    sendMessage(message: string): void;
    receiveMessage(): string;
}

Let’s start by looking at the MessageSender interface, which simply defines the two operations we want to perform, sendMessage and receiveMessage.

import { MessageSender } from './message-sender';

export class DesktopSender implements MessageSender {
    sendMessage(message: string): void {
        console.log("Sending message from a desktop: " + message);
    }

    receiveMessage(): string {
        return "Message received on a desktop.";
    }
}

import { MessageSender } from './message-sender';

export class MobileSender implements MessageSender {
    sendMessage(message: string): void {
        console.log("Sending message from a mobile device: " + message);
    }

    receiveMessage(): string {
        return "Message received on a mobile device.";
    }
}

In this case, the codes are identical to those we had in the solution without the pattern. In fact, this is because these are the concrete implementations we had in the solution without the pattern. Therefore, here we have simply created a common interface for both classes. This simple change could have been made without having the bridge pattern, and we would already have gained in decoupling our first solution. However, what the bridge pattern will allow us to do is to grow in the concrete implementations on the one hand and the abstractions on the other.

The abstract MessagingService class has an attribute that satisfies the MessageSender interface. In this case, we include it through the constructor but we could do it from an accessor method.

The key is that we define the methods that we want the abstractions to have, in our case the send and receive methods that will be implemented in the hierarchy of abstraction classes.

import { MessageSender } from './message-sender';

export abstract class MessagingService {
    protected sender: MessageSender;

    constructor(sender: MessageSender) {
        this.sender = sender;
    }

    abstract send(message: string): void;
    abstract receive(): string;
}

In the following concrete implementation of the previous abstraction, we extend the MessagingService class and therefore, we already have the sender attribute thanks to the parent class. Now, we make the concrete implementation of the send and receive methods, where in both cases we are making use of the methods of the instance of the sender attribute, delegating the responsibility to this instance.

import { MessagingService } from './messaging-sender';

export class AdvancedMessaging extends MessagingService {
    send(message: string): void {
        this.sender.sendMessage(message);
    }

    receive(): string {
        return this.sender.receiveMessage();
    }
}

If we look at the final code, we can see that when we are creating the platform to send mobile messages, we will create an instance of the AdvancedMessaging abstraction by receiving an object of the MobileSender instance. On the other hand, if it were to send desktop messages, it would be exactly the same but instead of passing a MobileSender instance as an argument, it would be a DesktopSender instance. Later, on both platforms we will use the methods that we have in the interface, the send methods to send messages and the receive method to receive them.

import { AdvancedMessaging } from "./advanced-messaging";
import { DesktopSender } from "./desktop-sender";
import { MobileSender } from "./mobile-sender";

class Client {
    static main(): void {
        // Use mobile sender
        const mobileMessaging = new AdvancedMessaging(new MobileSender());
        mobileMessaging.send("Hello from Mobile!");
        console.log(mobileMessaging.receive());

        // Use desktop sender
        const desktopMessaging = new AdvancedMessaging(new DesktopSender());
        desktopMessaging.send("Hello from Desktop!");
        console.log(desktopMessaging.receive());
    }
}

Client.main();

This design using the bridge pattern allows you to easily change the message sending implementation without modifying the rest of the client code or the messaging application logic. Each component can be developed, tested, and maintained independently.

Differences between Bridge, Strategy, and Template Method

Although the Bridge, Strategy, and Template Method patterns share certain similarities, each one has a different purpose and structure. Here’s a description of the key differences between them:

Bridge Pattern:

• Purpose: The Bridge pattern focuses on separating an abstraction from its implementation so that both can vary independently.
• Structure: It typically involves defining an abstraction hierarchy and an implementation hierarchy, with a bridge connecting the two hierarchies.
• Use Cases: It is useful when there is a need to support multiple implementations of an abstraction, or when changes in one part of the system should not affect unrelated parts.

Strategy Pattern:

• Purpose: The Strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. It allows the algorithm to vary independently from the client that uses it.
• Structure: It involves defining a strategy interface that represents a family of algorithms, and concrete implementations of these algorithms.
• Use Cases: It is beneficial when there are multiple algorithms for a specific task and the client needs to select or switch between them dynamically.

Template Method Pattern:

• Purpose: The Template Method pattern defines the skeleton of an algorithm in a method, deferring some steps to subclasses. It allows subclasses to redefine certain steps of an algorithm without changing its structure.
• Structure: It typically involves defining an abstract class that contains the template method (the algorithm skeleton) and abstract methods that subclasses must implement.
• Use Cases: It is useful when there is a common algorithm structure shared among multiple subclasses, but the specific implementation of certain steps may vary.

In summary, while the Bridge pattern focuses on separating abstraction from implementation, the Strategy pattern deals with encapsulating interchangeable algorithms, and the Template Method pattern defines the skeleton of an algorithm with certain steps delegated to subclasses. Each pattern addresses different concerns and can be applied in different scenarios based on the specific requirements of the system.

Conclusions

Some conclusions about the use of the Bridge design pattern:

1. Abstraction and Implementation Separation: The Bridge pattern allows for the separation of abstraction from its implementation, facilitating the modification and extension of both independently. This promotes a more flexible and scalable design.
2. Coupling Reduction: By separating abstraction from implementation, the Bridge pattern helps reduce coupling between parts of the system. This makes the code easier to maintain and prevents the propagation of changes in one part of the system to unrelated parts.
3. Support for Various Platforms: The Bridge pattern is especially useful when working with multiple platforms or operating systems. It allows an abstraction to have multiple implementations that are specific to each platform, facilitating adaptation to different environments.
4. Promotion of Reusability and Modularity: By defining a hierarchy of abstraction and implementation, the Bridge pattern encourages code reuse and modularity. Abstractions and implementations can be easily exchanged and reused in different contexts, reducing duplication and promoting cohesion in software design.
5. Additional Complexity: Although the Bridge pattern can improve code flexibility and maintainability, it also introduces an additional layer of complexity in the design. This may require extra effort to understand and maintain the code, especially in small or simple systems where the separation between abstraction and implementation may seem unnecessary.

Overall, the Bridge pattern is a powerful tool for designing flexible and modular systems, especially when working with multiple platforms or operating systems. However, its use should be carefully evaluated based on the specific requirements of the project and the balance between flexibility and complexity in software design.

The most important thing about this pattern is not the concrete implementation of it but the ability to recognize the problem that this pattern can solve and when it can be applied. The specific implementation isn’t as important since that will vary depending on the programming language used.

The GitHub’s repository is the following:
https://github.com/Caballerog/blog/tree/master/bridge-pattern

There are 23 classic design patterns described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Chain of Responsibility pattern works and when it should be applied.

Responsibility of Chain: Basic Idea

Wikipedia provides us with the following definition:

“The chain-of-responsibility pattern is a design pattern consisting of a source of command objects and a series of processing objects. Each processing object contains logic that defines the types of command objects that it can handle; the rest are passed to the next processing object in the chain. A mechanism also exists for adding new processing objects to the end of this chain.” — Wikipedia

On the other hand, the definition provided by the original book is as follows:

“Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.”

On many occasions, we have a set of handlers (operations) that can be applied to an object (request) but we do not know, a priori, which handler should be applied to said object, nor whether one or more handlers should be applied to the request. The chain of responsibility pattern allows us to achieve more efficient and less coupled code since it avoids the previously mentioned issue. It also has other advantages regarding code maintainability. Here’s the UML pattern of this pattern:

These are the classes that comprise this pattern:

• Handler is the interface for handling requests. Although optional, most implementations also specify the successor link.

• ConcreteHandler are the concrete implementations that are responsible for handling the requests. Also, it can access its successor. The behavior of these classes is quite simple: if it can handle the request it will do it, otherwise, it will delegate the responsibility to the next handler.

• Client is responsible for initiating the sequence of request handlers (ConcreteHandler).

Responsibility of Chain: When to Use It

• When there is more than one object that can handle a request, and it happens that the handler is not known a priori. Also, we need the handler to be selected automatically.

• The set of objects that can handle a request can be specified dynamically.

• A request is handled by one or more objects without explicitly specifying the recipient.

Chain of Responsibility Pattern: Advantages and Disadvantages

The chain of responsibility pattern has a number of advantages, summarized in the following points:

• The code is more maintainable because it is less coupled between the object and the other object handles a request. The object (sender) only needs to know that a request will be handled by the handler. That is to say that both (receiver and the sender) have no explicit knowledge of each other. Besides, the object in the chain doesn’t need to know about the chain’s structure.

• Clean code. The Open-Closed Principle (OCP) is guaranteed since new handlers can be introduced without breaking the existing code in the chain.

• Cleaner code. The Single Responsibility Principle (SRP) is respected since the responsibility of each handler is transferred to its handle method instead of having that business logic in the client code.

A well-known drawback of this pattern is that the receipt isn’t guaranteed. That’s due to the fact that the request has no explicit receiver. Therefore, the request can fall off the end of the chain without ever being handled.

Finally, the main drawback of the chain of responsibility pattern — like most design patterns — is that there’s an increase in code complexity and the number of classes required for the code. With that said, this disadvantage is well known when applying design patterns — it’s the price to pay for gaining abstraction in the code.

Responsibility of Chain Examples

Next, we are going to illustrate with two examples of the Responsibility of Chain pattern:

• The basic structure of the Responsibility of Chain pattern. In this example, we are going to translate the theoretical UML diagram into TypeScript code to identify each of the classes involved in the pattern.

• A middleware-based authentication system. Three middlewares are developed that allow validating the existence of a user, password-based authentication, and finally the role of the user.

The following examples will show the implementation of this pattern using TypeScript. We have chosen TypeScript to carry out this implementation rather than JavaScript. The latter lacks interfaces or abstract classes, so the responsibility of implementing both the interface and the abstract class would fall on the developer.

Example 1: Basic Structure of the Responsibility of Chain Pattern

In this first example, we’re going to translate the theoretical UML diagram into TypeScript to test the potential of this pattern. This is the diagram to be implemented:

First, we are going to define the interface (Handler) of our problem. This interface defines two methods next and handle. The first method is in charge of linking each handler with the next. While the second method is in charge of carrying out the specific operation of each of the handlers.

The next class to define is AbstractHandler. This class implements the interface and is, by definition, abstract — because there can be methods that are implemented in concrete classes. Normally, the abstract method is the one that handles the request (handler). However, in our concrete example we have implemented this function in such a way as to check that if there is a following handler, pass it on the responsibility of handling the request, and in the event that there are no more handlers, we simply stop in the chain of responsibility.

Another interesting point is to see how there is a reflexive relationship that allows defining the nextHandler attribute, which is the next handler in the chain. Finally, this class defines the assignment accessor method for the nextHandler attribute.

The next step is to define each of the concrete handlers, which will extend from the abstract class but will have concrete implementations of the handle method. Specifically, we can see that in the basic example what we do is check in each of the handlers if the request they receive corresponds to the one they know how to manage, and if not, we derive the responsibility to the next handler of the chain of responsibility through the method implemented in the AbstractHandler class.

Finally, we have to define the client code, which makes use of this pattern. In this case, we are going to declare the three handlers (HandlerA, HandlerB and HandlerC), and assign the order of the following responsibility chain the following order: A → B → C.

Later, we’ll simulate three requests for each of the handlers through the auxiliary function ClientCode.

In the first case, you can see how the three options have been managed and the managers who are responsible for them.

In the second case, we are going to omit HandlerA from the chain of responsibility and repeat the three requests again. The result will be that neither HandlerB nor HandlerC is able to handle the request corresponding to OptionA.

Example 2: Middlewares Using Chain of Responsibility

In this example, we are going to use the chain of responsibility pattern to simulate an authentication and authorization system using a set of middlewares that applies checks on a request.

As we did in the previous example, let’s start by taking a look at the UML diagram that is going to help us identify each of the parts that this pattern is composed of.

Notice that our class diagram incorporates some extra classes. These give context to our problem, but the chain of responsibility pattern can easily be identified among the set of classes.

Before we address the implementation of our problem, let’s define a set of constants that will give us semantic value to these values. These three constants are quite simple: Firstly, we have two fake users (USERS), secondly, the number of maximum authentication requests per minute (REQUEST_PER_MINUTE), and finally the waiting time in milliseconds when the number of requests per minute is exceeded (WAIT_TIME).

We start to define the pattern again by defining the Handler interface with the same two methods as in the basic structure of the pattern. In other words, the Handler interface is made up of the setNextMiddleware and execute methods, the first being in charge of linking each of the middleware and the second method is responsible for handling the request.

In our case, the request that we have to handle is the one composed by a User.

The objects that behave as users must satisfy the User interface, which is simply composed of an email and a password. The goal of this tutorial is to understand the chain of responsibility pattern, so this part will be simple — but complete enough to solve the authentication and authorization problem.

Continuing with the pattern, the next element is the development of the abstract class, Middleware, that implements the Handler interface. In this implementation, there is the setNextMiddleware method, which allows linking the following middleware, and the execute method, which is abstract and is implemented in each of the specific middleware. Finally, we have the checkNext method that checks if we have reached the end of the middleware chain, responding true when all the checks have been passed. If there is a next middleware then the next middleware check will be executed.

The first middleware we need to build for the authentication and authorization system is verification that the user exists.

In our example, we have modeled a fake server where we have two registered users (the same ones that we previously defined in the constants). This server, which we will see later, provides us an API with the hasEmail and isValidPassword methods. The execute method will receive the request (a User) and we would make the checks to ensure the user exists on the server. First, it checks if the email exists on the server; if so, the username and password are checked. If the check is passed, the checkNext method is executed, which consists of making the request to the next middleware.

The following middleware would be the one that allows us to control the number of requests per minute.

This is where you can see the Open-Close Principle (OCP) — it is very easy to incorporate new middleware and checks without breaking the existing code. You can also see the Single Responsibility Principle(SRP) since each middleware has only one responsibility.

In this middleware, we receive the maximum number of requests per minute as a parameter. In addition, this middleware has some private attributes that allow you to control the time that has passed between requests, and the number of attempts that have been made in one minute.

If you look at the logic of the execute method, it’s quite simple — but you can check how a check exists again. This is what stops the chain of responsibility since it’s resolved by this handler.

In case the check is passed, this middleware, like the previous one, will proceed to pass the request to the next middleware.

Finally, the following middleware is in charge of checking if the user is an administrator or not, obviously, this should have been done with a real check on a knowledge base. However, to illustrate that each middleware can have different parameters, a basic check has been performed.

In the case of being admin, the chain of responsibility is finished. Otherwise, it continues. This is so that when a new middleware is developed, it can be managed in the chain. In our case, here we end the responsibility chain because we do not have any more middleware implemented.

For educational purposes, we have built a Server class that stores users on a Map<String, User> and has a Middleware that is the one that begins the chain of responsibility.

The register, hasEmail and isValidPassword methods are focused on performing these operations using the users who are registered on the server.

The logIn method receives the request with the user. The chain of responsibility begins on line 13 with the execution of the middleware sending the user as a request.

Finally, the client that makes use of our middleware system is the one shown in the code. A server has been created and two user accounts registered, obviously this would be our real backend and should not have been done here.

Subsequently, the chain of responsibilities is indicated using the following middleware in the following order:

UserExists -> Trottling -> Role

Finally, we have created a loop in which email and password are requested.

To end this article we are going to see the code working and for this I have recorded several GIFs.

In the first, we can see the UserExists and Throttling middleware in operation. I have entered the wrong email and password several times, the first middleware (Throttling) will leave the responsibility the first two times to the UserExists middleware, which rejects the validation of the user/password. From the third time the credentials are entered, the Throttling middleware will be in charge of managing the request.

The role middleware is the one that manages the request when the credentials corresponding to the admin role are entered.

Finally, I’ve created two npm scripts through which the code presented in this article can be executed:

    npm run example1
    npm run example2

See this GitHub repo for the full code.

Conclusion

Chain of responsibility is a design pattern that allows you to respect the Open-Closed Principle since a new Handler can be created without breaking the existing code. In addition, this allows you to comply with the Single Responsibility Principle (SRP) since each handler only has a single responsibility to resolve. Another very interesting point of this pattern is that it is not necessary to know, a priori, which handler should resolve the request, which allows you to make the decision at runtime.

The most important thing about this pattern is not the concrete implementation of it but the ability to recognize the problem that this pattern can solve and when it can be applied. The specific implementation isn’t as important since that will vary depending on the programming language used.

There are 23 classic design patterns which are described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Observer Pattern works and when it should be applied.

Observer Pattern: Basic Idea

Wikipedia provides us with the following definition:

The observer pattern is a software design pattern in which an object, named the subject, maintains a list of its dependents, called observers, and notifies them automatically of any state changes, usually by calling one of their methods. — Wikipedia

On the other hand, the definition provided by the original book is the following:

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically. — Design Patterns: Elements of Reusable Object-Oriented Software

On many occasions we need to communicate system objects without coupling them either at code or at communication mechanism level. Should we have a group of objects (observers) that are required to be aware of the state of another object (observable), there are different techniques for carrying out the communication between them. The most popular techniques are:

1. Busy waiting. A process repeatedly verifies a condition. In our case, it would be an observer constantly checking whether or not the observable's condition has changed. This strategy could be a valid solution in certain cases, but it isn't an adequate solution for our scenario, since it would imply having several processes (observers) consuming resources without performing any operations, causing an exponential performance decrease in the number of existing observers.

2. Polling. In this case, the query operation is performed with a small window of time between operations. This is an attempt to implement synchronism between processes. However, we can once again appreciate degradation in the system's performance, furthermore, depending on the time set between each query, the information can be so delayed that it might be invalid causing a wastage of resources used by this technique.

The following codes show implementations of the previous techniques:

Busy-Waiting:

while(!condition){
   // Query
   if(isQueryValid) condition = true;
}

Polling:

function refresh() {
    setTimeout(refresh, 5000);
    // Query
}

// initial call, or just call refresh directly
setTimeout(refresh, 5000);

Although it isn't the goal of this post, it's a good idea to understand the two alternative techniques to this design pattern. Therefore, we can say that, in a nutshell, the difference between the active wait and polling techniques is that in the former the query operation is performed all the time, while in the latter there are intervals of time where the operation isn't executed.

Busy-Waiting:

while(resourceIsNotReady()){
  //Do nothing
}

Polling:

while(resourceIsNotReady()){
     Sleep(1000); // 1000 or anytime
 }

The Observer pattern allows us to achieve a more efficient and less coupled code, since it avoids the previously mentioned issue, as well as having other advantages regarding code maintainibility. The UML pattern of this pattern is the following:

The classes that comprise this pattern are the following:

• Subject is the interface that every observed class implements. This interface contains the attach and detach methods that allow us to add and remove observers from the class. It also contains a notify method, which is responsible for notifying all of the observers that a change has occurred in the observed. Also, all of the subjects store references of the objects that observe them (observers).

• Observer is the interface that all of the ConcreteObservers implement. In this interface, the update method is defined, which contains the business logic to be executed by each observer upon receiving the change notification from the Subject.

• ConcreteSubject is the concrete implementation of the Subject class.
  This class defines the state of the SubjectState application, which must be notified when a change occurs. For this reason, the accessor methods (getState and setState) are usually implemented, since they manipulate the state. This class is also responsible for sending the notification to all of its observers when the state changes.

• ConcreteObserver is the class that models each of the concrete observers. In this class the update method belonging to the Observer interface is implemented, which is responsible for maintaining its state consistently which is responsible for keeping its state consistent with the subject objects it is observing.

Nowadays there's a family of libraries known as Reactive Extensions or ReactiveX which have made this design pattern popular. The Reactive Extensions make use of two design patterns: 1) Observer 2) Iterator. They also have a group of operators that use functional programming. These are some of the most popular Reactive Exntensions:

• Java: RxJava

• JavaScript: RxJS

• C#: Rx.NET

• C#(Unity): UniRx

In these implementations, there are differences in the naming of classes and methods. The following names are the most extended:

1. Subscriber corresponds with the class Observer.

2. ConcreteSubscribers correspond with the classes ConcreteObservers.

3. The Subject class is maintained. The attach and detach methods are renamed to subscribe and unsubscribe.

4. The ConcreteSubjects classes are concrete implementations, like BehaviorSubject, ReplaySubject o AsyncSubject.

Observer Pattern: Communication Strategies

There are two communication strategies between Subjects (observables) and Observers (observadores) in the observer pattern:

• Pull. In this model, the subject sends the minimum information to the observers and they are responsible for making inquiries to obtain more detail. This model focuses on the fact that the Subject ignores the observers.

• Push. In this model, the subject sends the greatest amount of information to the observers the information of the change produced, regardless of whether they wanted it or not. In this model, the Subject knows in depth the needs of each of its observers.

Although a priori it may seem that the push communication technique is less reusable due to the fact that the Subject must have knowledge about the observers, this is not always the case. On the other hand, the pull based communication technique can be inefficient because the observers have to figure out what changed without help from the Subject.

Observer Pattern: When To Use

1. When there is a one-to-many dependency between system objects so that when the object changes state, all dependent objects need to be notified automatically.

2. You do not want to use [busy-waiting] (https://en.wikipedia.org/wiki/Busy_waiting) and [Polling] (https://en.wikipedia.org/wiki/Polling_(computer_science)) to update observers.

3. Decouple the dependencies between the Subject objects (Observables) and the Observers (Observers) allowing to respect the Open-Closed Principle.

Observer Pattern: Advantages and Disadvantages

The Observer pattern has a number of advantages that can be summarized in the following points:

• The code is more maintainable because it is less coupled between the observable classes and their dependencies (the observers).

• Clean code since the Open-Closed Principle is guaranteed due to the new observers (subscribers) can be introduced without breaking the existing code in the observable (and vice versa).

• Cleaner code because the Single Responsibility Principle (SRP) is respected since the responsibility of each observer is transferred to its update method instead of having that business logic in the Observable object.

• Relationships between objects can be established at runtime rather than at compile time.

However, the main drawback of the observer pattern, like most design patterns, is that there is an increase in complexity in the code, and an increase in the number of classes required for the code. Although, this disadvantage is well known when applying design patterns since the price to pay for gaining abstraction in the code.

Observer Pattern Examples

Next, we are going to illustrate two examples of application of the Observer pattern:

1. Basic structure of the Observer pattern. In this example we are going to translate the theoretical UML diagram into TypeScript code to identify each of the classes involved in the pattern.

2. An auction system in which there is an object (subject) that emits the change produced (push technique) in the price of a product that is being auctioned to all observers (observer) interested in acquiring that product. Every time the price of the product auction increases because some observer has increased the bid, it is notified to all observers.

The following examples will show the implementation of this pattern using TypeScript. We have chosen TypeScript to carry out this implementation rather than JavaScript — the latter lacks interfaces or abstract classes so the responsibility of implementing both the interface and the abstract class would fall on the developer.

Example 1: Basic structure of the observer pattern

In this first example, we're going to translate the theoretical UML diagram into TypeScript to test the potential of this pattern. This is the diagram to be implemented:

First, we are going to define the interface (Subject) of our problem. Being an interface, all the methods that must be implemented in all the specific Subject are defined, in our case there is only one ConcreteSubject. The Subject interface defines the three methods necessary to comply with this pattern: attach, detach and notify. The attach and detach methods receive the observer as a parameter that will be added or removed in the Subject data structure.

import { Observer } from "./observer.interface";

export interface Subject {
  attach(observer: Observer): void;
  detach(observer: Observer): void;
  notify(): void;
}

There can be as many ConcreteSubject as we need in our problem. As this problem is the basic scheme of the Observer pattern, we only need a single ConcreteSubject. In this first problem, the state that is observed is the state attribute, which is of type number. On the other hand, all observers are stored in an array called observers. The attach and detach methods check whether or not the observer is previously in the data structure to add or remove it from it. Finally, the notify method is in charge of invoking the update method of all the observers that are observing the Subject.

Objects of the ConcreteSubject class perform some task related to the specific business logic of each problem. In this example, there is a method called operation that is in charge of modifying the state and invoking the notify method.

import { Observer } from "./observer.interface";
import { Subject } from "./subject.interface";

export class ConcreteSubject implements Subject {
  public state: number;
  private observers: Observer[] = [];

  public attach(observer: Observer): void {
    const isAttached = this.observers.includes(observer);
    if (isAttached) {
      return console.log("Subject: Observer has been attached already");
    }

    console.log("Subject: Attached an observer.");
    this.observers.push(observer);
  }

  public detach(observer: Observer): void {
    const observerIndex = this.observers.indexOf(observer);
    if (observerIndex === -1) {
      return console.log("Subject: Nonexistent observer");
    }

    this.observers.splice(observerIndex, 1);
    console.log("Subject: Detached an observer");
  }

  public notify(): void {
    console.log("Subject: Notifying observers...");
    for (const observer of this.observers) {
      observer.update(this);
    }
  }

  public operation(): void {
    console.log("Subject: Business Logic.");
    this.state = Math.floor(Math.random() * (10 + 1));

    console.log(`Subject: The state has just changed to: ${this.state}`);
    this.notify();
  }
}

The other piece of this design pattern is the observer. Therefore, let's start by defining the Observer interface which only needs to define the update method which is in charge of executing every time an observer is notified that a change has occurred.

import { Subject } from "./subject.interface";

export interface Observer {
  update(subject: Subject): void;
}

Each class that implements this interface must include its business logic in the update method. In this example two ConcreteObservers have been defined, which will perform actions according to the Subjects state. The following code shows two concrete implementations for two different types of observers: ConcreteObserverA and ConcreteObserverB.

import { ConcreteSubject } from "./concrete-subject";
import { Observer } from "./observer.interface";
import { Subject } from "./subject.interface";

export class ConcreteObserverA implements Observer {
  public update(subject: Subject): void {
    if (subject instanceof ConcreteSubject && subject.state < 3) {
      console.log("ConcreteObserverA: Reacted to the event.");
    }
  }
}

import { ConcreteSubject } from "./concrete-subject";
import { Observer } from "./observer.interface";
import { Subject } from "./subject.interface";

export class ConcreteObserverB implements Observer {
  public update(subject: Subject): void {
    if (
      subject instanceof ConcreteSubject &&
      (subject.state === 0 || subject.state >= 2)
    ) {
      console.log("ConcreteObserverB: Reacted to the event.");
    }
  }
}

Finally, we define our Client or Context class, which makes use of this pattern. In the following code the necessary classes to simulate the use of Subject and Observer are implemented:

import { ConcreteObserverA } from "./concrete-observerA";
import { ConcreteObserverB } from "./concrete-observerB";
import { ConcreteSubject } from "./concrete-subject";

const subject = new ConcreteSubject();

const observer1 = new ConcreteObserverA();
subject.attach(observer1);

const observer2 = new ConcreteObserverB();
subject.attach(observer2);

subject.operation();
subject.operation();

subject.detach(observer2);

subject.operation();

Example 2 — Auctions using Observer

In this example we're going to use the Observer pattern to simulate an action house in which a group of auctioneers (Auctioneer) bid for different products (product). The auction is directed by an agent (Agent). All of our auctioneers need to be notified each time one of them increases their bid, so that they can decide whether to continue bidding or to retire.

Like we did in the previous example, let's begin by taking a look at the UML diagram that is going to help us identify each of the parts that this pattern is composed of.

The product that is being auctioned is the Subject's state, and all of the observers await notifications whenever it changes. Therefore, the product class is comprised of three attributes: price, name and auctioneer (the auctioneer that is assigned the product).

import { Auctioneer } from "./auctioneer.interface";

export class Product {
  public price;
  public name;
  public auctionner: Auctioneer = null;

  constructor(product) {
    this.price = product.price || 10;
    this.name = product.name || "Unknown";
  }
}

The Agent is the interface that defines the methods for managing the group of Auctioneers, and notifying them that the bid on the auctioned product has changed. In this case, the attach and detach methods have been renamed to subscribe and unsubscribe.

import { Auctioneer } from "./auctioneer.interface";

export interface Agent {
  subscribe(auctioneer: Auctioneer): void;
  unsubscribe(auctioneer: Auctioneer): void;
  notify(): void;
}

The concrete implementation of the Agent interface is performed by the ConcreteAgent class. As well as the three methods previously described, which have a very similar behavior to the one presented in the previous example, the bidUp method has been implemented, which, after making some checks on the auctioneer's bid, assigns it as valid and notifies all of the auctioneers of the change.

import { Agent } from "./agent.interface";
import { Auctioneer } from "./auctioneer.interface";
import { Product } from "./product.model";

export class ConcreteAgent implements Agent {
  public product: Product;
  private auctioneers: Auctioneer[] = [];

  public subscribe(auctioneer: Auctioneer): void {
    const isExist = this.auctioneers.includes(auctioneer);
    if (isExist) {
      return console.log("Agent: Auctioneer has been attached already.");
    }

    console.log("Agent: Attached an auctioneer.");
    this.auctioneers.push(auctioneer);
  }

  public unsubscribe(auctioneer: Auctioneer): void {
    const auctioneerIndex = this.auctioneers.indexOf(auctioneer);
    if (auctioneerIndex === -1) {
      return console.log("Agent: Nonexistent auctioneer.");
    }

    this.auctioneers.splice(auctioneerIndex, 1);
    console.log("Agent: Detached an auctioneer.");
  }

  public notify(): void {
    console.log("Agent: Notifying auctioneer...");
    for (const auctioneer of this.auctioneers) {
      auctioneer.update(this);
    }
  }

  public bidUp(auctioneer: Auctioneer, bid: number): void {
    console.log("Agent: I'm doing something important.");
    const isExist = this.auctioneers.includes(auctioneer);
    if (!isExist) {
      return console.log("Agent: Auctioneer there is not in the system.");
    }
    if (this.product.price >= bid) {
      console.log("bid", bid);
      console.log("price", this.product.price);
      return console.log(`Agent: ${auctioneer.name}, your bid is not valid`);
    }
    this.product.price = bid;
    this.product.auctionner = auctioneer;

    console.log(
      `Agent: The new price is ${bid} and the new owner is ${auctioneer.name}`
    );
    this.notify();
  }
}

In this problem there are four different types of Auctioneer defined in the AuctioneerA, AuctioneerB, AuctioneerC and AuctioneerD classes. All of these auctioneers implement the Auctioneer interface, which defines the name, MAX_LIMIT and the update method. The MAX_LIMIT attribute defines the maximum amount that can be bid by each type of Auctioneer.

import { Agent } from "./agent.interface";

export interface Auctioneer {
  name: string;
  MAX_LIMIT: number;
  update(agent: Agent): void;
}

The different types of Auctioneer have been defined, to illustrate that each one will have a different behavior upon receiving the Agents notification in the update method. Nevertheless, all that has been modified in this example is the probability of continuing to bid and the amount they increase their bids by.

import { Agent } from "./agent.interface";
import { Auctioneer } from "./auctioneer.interface";
import { ConcreteAgent } from "./concrete-agent";

export class ConcreteAuctioneerA implements Auctioneer {
  name = "ConcreteAuctioneerA";
  MAX_LIMIT = 100;

  public update(agent: Agent): void {
    if (!(agent instanceof ConcreteAgent)) {
      throw new Error("ERROR: Agent is not a ConcreteAgent");
    }

    if (agent.product.auctionner === this) {
      return console.log(`${this.name}: I'm the owner... I'm waiting`);
    }

    console.log(`${this.name}: I am not the owner... I'm thinking`);
    const bid = Math.round(agent.product.price * 1.1);
    if (bid > this.MAX_LIMIT) {
      return console.log(`${this.name}: The bid is higher than my limit.`);
    }
    agent.bidUp(this, bid);
  }
}

import { Agent } from "./agent.interface";
import { Auctioneer } from "./auctioneer.interface";
import { ConcreteAgent } from "./concrete-agent";

export class ConcreteAuctioneerB implements Auctioneer {
  name = "ConcreteAuctioneerB";
  MAX_LIMIT = 200;

  public update(agent: Agent): void {
    if (!(agent instanceof ConcreteAgent)) {
      throw new Error("ERROR: Agent is not a ConcreteAgent");
    }

    if (agent.product.auctionner === this) {
      return console.log(`${this.name}: I'm the owner... I'm waiting`);
    }

    console.log(`${this.name}: I am not the owner... I'm thinking`);
    const isBid = Math.random() < 0.5;
    if (!isBid) {
      return console.log(`${this.name}: I give up!`);
    }
    const bid = Math.round(agent.product.price * 1.05);
    if (bid > this.MAX_LIMIT) {
      return console.log(`${this.name}: The bid is higher than my limit.`);
    }
    agent.bidUp(this, bid);
  }
}

import { Agent } from "./agent.interface";
import { Auctioneer } from "./auctioneer.interface";
import { ConcreteAgent } from "./concrete-agent";

export class ConcreteAuctioneerC implements Auctioneer {
  name = "ConcreteAuctioneerC";
  MAX_LIMIT = 500;

  public update(agent: Agent): void {
    if (!(agent instanceof ConcreteAgent)) {
      throw new Error("ERROR: Agent is not a ConcreteAgent");
    }

    if (agent.product.auctionner === this) {
      return console.log(`${this.name}: I'm the owner... I'm waiting`);
    }

    console.log(`${this.name}: I am not the owner... I'm thinking`);
    const isBid = Math.random() < 0.2;
    if (!isBid) {
      return console.log(`${this.name}: I give up!`);
    }
    const bid = Math.round(agent.product.price * 1.3);
    if (bid > this.MAX_LIMIT) {
      return console.log(`${this.name}: The bid is higher than my limit.`);
    }
    agent.bidUp(this, bid);
  }
}

import { Agent } from "./agent.interface";
import { Auctioneer } from "./auctioneer.interface";
import { ConcreteAgent } from "./concrete-agent";

export class ConcreteAuctioneerD implements Auctioneer {
  name = "ConcreteAuctioneerD";
  MAX_LIMIT = 1000;

  public update(agent: Agent): void {
    if (!(agent instanceof ConcreteAgent)) {
      throw new Error("ERROR: Agent is not a ConcreteAgent");
    }

    if (agent.product.auctionner === this) {
      return console.log(`${this.name}: I'm the owner... I'm waiting`);
    }

    console.log(`${this.name}: I am not the owner... I'm thinking`);
    const isBid = Math.random() < 0.8;
    if (!isBid) {
      return console.log(`${this.name}: I give up!`);
    }
    const bid = Math.round(agent.product.price * 1.2);
    if (bid > this.MAX_LIMIT) {
      return console.log(`${this.name}: The bid is higher than my limit.`);
    }
    agent.bidUp(this, bid);
  }
}

Finally, let's show the Client class, which makes use of the observer pattern. In this example, an auction house is declared, with an Agent and four Auctioneers, where two different products (diamond and gem) are being auctioned. In the first auction, all four auctioneers participate. In the second auction, the D class auctioneer retires leaving the three remaining to participate.

import { ConcreteAgent } from "./concrete-agent";
import { ConcreteAuctioneerA } from "./concrete-auctioneerA";
import { ConcreteAuctioneerB } from "./concrete-auctioneerB";
import { ConcreteAuctioneerC } from "./concrete-auctioneerC";
import { ConcreteAuctioneerD } from "./concrete-auctioneerD";
import { Product } from "./product.model";

const concreteAgent = new ConcreteAgent();

const auctioneerA = new ConcreteAuctioneerA();
const auctioneerB = new ConcreteAuctioneerB();
const auctioneerC = new ConcreteAuctioneerC();
const auctioneerD = new ConcreteAuctioneerD();

concreteAgent.subscribe(auctioneerA);
concreteAgent.subscribe(auctioneerB);
concreteAgent.subscribe(auctioneerC);
concreteAgent.subscribe(auctioneerD);

const diamond = new Product({ name: "Diamond", price: 5 });
concreteAgent.product = diamond;

concreteAgent.bidUp(auctioneerA, 10);

console.log("--------- new Bid-----------");

concreteAgent.unsubscribe(auctioneerD);

const gem = new Product({ name: "Gem", price: 3 });
concreteAgent.product = gem;

concreteAgent.bidUp(auctioneerB, 5);

console.log(`The winner of the bid is 
             Product: ${diamond.name}
             Name: ${diamond.auctionner.name}
             Price: ${diamond.price}`);

console.log(`The winner of the bid is 
             Product: ${gem.name}
             Name: ${gem.auctionner.name}
             Price: ${gem.price}`);

Finally, I've created two npm scripts, through which the code presented in this article can be executed:

npm run example1
npm run example2

GitHub Repo available here.

Conclusion

Observer is a design pattern that allows respecting the Open-Closed Principle since new Subject and Observer can be created without breaking the existing code. In addition, it allows communication between two actors of the system without the need for them to be linked in the knowledge of each other. Finally, the performance degradation that occurs in more elementary techniques such as busy-waiting and polling is overcome.

Finally, the most important thing about this pattern is not the concrete implementation of it, but being able to recognize the problem that this pattern can solve, and when it can be applied. The specific implementation is the least of it, since it will vary depending on the programming language used.

There are 23 classic design patterns which are described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Abstract-Factory Pattern works and when it should be applied.

--

Abstract Factory: Basic Idea

Wikipedia provides us with the following definition:

The abstract factory pattern provides a way to encapsulate a group of individual factories that have a common theme without specifying their concrete classes — Wikipedia

On the other hand, the definition provided by the original book is the following:

Provide an interface for creating families of related or dependent objects without specifying their concrete classes — Design Patterns: Elements of Reusable Object-Oriented Software

On many occasions, we need to create different types of objects that are not known a priori from a list of possible objects in which these objects are related in the creation process. The natural tendency is to create a factoryManager class that allows us to obtain the different types of objects based on a parameter. However, this solution has two serious drawbacks that we will describe throughout this article:

1. It breaks the principle of Open-Closed Principle which gives code that is not clean; and that it is not easy to maintain when the software scales.

2. The factoryManager class is attached to all types of objects that you want to build, creating code known as spaghetti code.

This problem and its solution have been dealt with in the article in which the Factory-Method design pattern is presented, which allows solving this problem when the creation of objects is simple and they are not related to each other. Therefore, it is recommended that you read this article first to later address this AbstractFactory pattern.

The Abstract Factory pattern allows for a clearer code, since it avoids the previously mentioned problem. The UML diagram of this pattern is as follows:

The classes that comprise this pattern are the following:

• AbstractProductA and AbstractProductB are the interfaces for a set of products of the same type but of a different family. In other words, all the products that implement the AbstractProductA class belong to the same product type, although they will be organized into different families. This type of object will be better understood in the concrete example that follows.

• ProductA1, ProductA2, ProductB1 and ProductB are concrete implementations of each type of AbstractProduct.

• AbstractFactory is the interface that declares the set of creation methods for each of the concrete factories (ConcreteFactory1 and ConcreteFactory2).

• ConcreteFactory1 and ConcreteFactory2 implement the creation methods of the AbstractFactory class for each of the product families.

Abstract Factory Pattern: When To Use

1. The problems solved by Abstract Factory are similar to those solved by the Factory-Method pattern, but with greater abstraction in the types of objects that need to be created. Therefore, in the case of Abstract Factory it is required to work with several families of products related to each other rather than in a set of products.

2. The family of objects with which the client must work is not known a priori. Rather, this knowledge depends directly on the interaction of another user with the system (end user or system).

3. In the event that it is necessary to extend the internal components (the number of families and objects that are created) without having to have the code coupled, but rather have interfaces and abstractions that allow to easily extend with factories and specific products.

Abstract Factory Pattern: Advantages and Disadvantages

The Abstract Factory pattern has a number of advantages that can be summarized in the following points:

• Compatibility between products created by the same factory class is guaranteed.

• Clean code as the Open-Closed Principle is guaranteed since new product families can be introduced without breaking the existing code.

• Cleaner code since the Single Responsibility Principle (SRP) is respected since the responsibility of creating the concrete product is transferred to the concrete creator class instead of the client class having this responsibility.

• Cleaner code because the Single Responsibility Principle (SRP) is respected since the responsibility of creating the concrete product is transferred to the concrete creator class instead of the client class having this responsibility.

However, the main drawback of the abstract factory pattern, like most design patterns, is that there is an increase in complexity in the code, and an increase in the number of classes required for the code. Although, this disadvantage is well known when applying design patterns for it is the price to pay for gaining abstraction in the code.

Abstract Factory Pattern Examples

Next, we are going to illustrate two examples of application of the Abstract Factory pattern:

1. Basic structure of the Abstract Factory pattern. In this example we are going to translate the theoretical UML diagram into TypeScript code to identify each of the classes involved in the pattern.

2. Creation of characters in a video game. Let's think of the classic WoW (World of Warcraft) in which the player can have a set of objects depending on the race they choose. For example, we will have the races: Humans, Orcs and Magicians; which will have weapons and armor (products) that will be different depending on the race (the family of objects).

The following examples will show the implementation of this pattern using TypeScript. We have chosen TypeScript to carry out this implementation rather than JavaScript — the latter lacks interfaces or abstract classes so the responsibility of implementing both the interface and the abstract class would fall on the developer.

Example 1: Basic structure of the abstract factory pattern

In this first example, we’re going to translate the theoretical UML diagram into TypeScript to test the potential of this pattern. This is the diagram to be implemented:

First, we are going to define the interfaces (AbstractProductA and AbstractProductB) that define the types of concrete products that we want to create for the different families. In our concrete example, to simplify the understanding of the pattern as much as possible, only one method has been defined for each of these interfaces: usefulFunctionA and usefulFunctionB respectively.

export interface AbstractProductA {
  usefulFunctionA(): string;
}

export interface AbstractProductB {
  usefulFunctionB(): string;
}

The next step is to define the specific products that implement each of these interfaces. In our case, two concrete objects will be implemented for each of these abstract classes. For the first interface (AbstractProductA) the classes ConcreteProductA1 and ConcreteProductA2 are implemented, while for the second interface (AbstractProductB) the classes ConcreteProductB1 and ConcreteProductB2 are implemented.

import { AbstractProductA } from "./abstract-productA";

export class ConcreteProductA1 implements AbstractProductA {
  public usefulFunctionA(): string {
    return "The result of the product A1.";
  }
}

import { AbstractProductA } from "./abstract-productA";

export class ConcreteProductA2 implements AbstractProductA {
  public usefulFunctionA(): string {
    return "The result of the product A2.";
  }
}

import { AbstractProductB } from "./abstract-productB";

export class ConcreteProductB1 implements AbstractProductB {
  public usefulFunctionB(): string {
    return "The result of the product B1.";
  }
}

import { AbstractProductB } from "./abstract-productB";

export class ConcreteProductB2 implements AbstractProductB {
  public usefulFunctionB(): string {
    return "The result of the product B2.";
  }
}

Once the structure of classes related to the creation of products has been defined, we proceed to define the structure of classes related to the creation of factories in charge of creating these objects. Therefore, first the abstract class AbstractFactory is defined in which the methods in charge of creating the concrete objects by the concrete factories are defined. However, note that these methods return the abstract classes from each of the AbstractProductA and AbstractProductB products.

import { AbstractProductA } from "./abstract-productA";
import { AbstractProductB } from "./abstract-productB";

export interface AbstractFactory {
  createProductA(): AbstractProductA;
  createProductB(): AbstractProductB;
}

Finally, it would be necessary to define the concrete factories, in which the concrete classes are instantiated. In this first example, the ConcreteFactory1 factory will be in charge of instantiating the concrete objects of family 1 (ConcreteProductA1 and ConcreteProductB1) and the ConcreteFactory2 factory will be in charge of instantiating the concrete objects of family 2 (ConcreteProductA2 and ConcreteProductB2).

import { AbstractFactory } from "./abstract-factory";
import { AbstractProductA } from "./abstract-productA";
import { AbstractProductB } from "./abstract-productB";
import { ConcreteProductA1 } from "./concrete-productA1";
import { ConcreteProductB1 } from "./concrete-productB1";

export class ConcreteFactory1 implements AbstractFactory {
  public createProductA(): AbstractProductA {
    return new ConcreteProductA1();
  }

  public createProductB(): AbstractProductB {
    return new ConcreteProductB1();
  }
}

import { AbstractFactory } from "./abstract-factory";
import { AbstractProductA } from "./abstract-productA";
import { AbstractProductB } from "./abstract-productB";
import { ConcreteProductA2 } from "./concrete-productA2";
import { ConcreteProductB2 } from "./concrete-productB2";

export class ConcreteFactory2 implements AbstractFactory {
  public createProductA(): AbstractProductA {
    return new ConcreteProductA2();
  }

  public createProductB(): AbstractProductB {
    return new ConcreteProductB2();
  }
}

Although it is not a direct part of the pattern, it would be necessary to see the execution of the pattern by the Client/Context class. In this case, the ClientCode method does not need to know the specific factory to create the products, but receiving an object of the AbstractFactory class as a parameter is sufficient to execute the CreateProductA and CreateProductB methods.

import { AbstractFactory } from "./abstract-factory";
import { ConcreteFactory1 } from "./concrete-factory1";
import { ConcreteFactory2 } from "./concrete-factory2";

function clientCode(factory: AbstractFactory) {
  const productA = factory.createProductA();
  const productB = factory.createProductB();

  console.log(productA.usefulFunctionA());
  console.log(productB.usefulFunctionB());
}

console.log("Client: Testing client code with ConcreteFactory1");
clientCode(new ConcreteFactory1());

console.log("----------------");

console.log("Client: Testing the same client code with ConcreteFactory2");
clientCode(new ConcreteFactory2());

Example 2 - Creation of Heroes equipment of a video game

We have already seen the theoretical example of this pattern, so you already understand the responsibilities of each of the classes of this pattern. Now, we are going to illustrate a real example in which we will identify each of the classes of this design pattern.

Our problem consists of the representation of the equipment of different heroes or characters in a video game. We will focus on the classic WoW video game (World of Warcraft), in which the heroes are divided into three races: Humans, orcs and wizards. Each of these heroes can have different armor (armor) and weapons (weapon) that vary depending on the race. Therefore, we can already identify that the products to be built will be the different types of armor and weapons, and the product families are the product family for a human, orc and wizard.

Therefore, following the same methodology as the one we have presented in the previous examples, we are going to start by looking at the UML diagram that will help us identify each of the parts of this pattern.

A priori, the class design of this problem may be impressive, but if we have understood the example of the basic structure of this pattern, we will understand this example perfectly.

We will start by creating each of the specific product types. That is, the first thing that is defined is the interface that models a weapon (weapon).

export interface Weapon {
  usefulFunction(): string;
}

To simplify the example, only one method called usefulFunction has been defined for each one of the weapons. Thus, the specific weapons that are defined are sword, axe and mage-fireball.

import { Weapon } from "./weapon.interface";

export class Sword implements Weapon {
  public usefulFunction(): string {
    return "The result of the Sword";
  }
}

import { Weapon } from "./weapon.interface";

export class Axe implements Weapon {
  public usefulFunction(): string {
    return "The result of the Axe";
  }
}

import { Weapon } from "./weapon.interface";

export class MageFireball implements Weapon {
  public usefulFunction(): string {
    return "The result of the MageFireball";
  }
}

In the same way that the weapon has been defined, the different armor (armor) is defined. In this specific case, we have created a collaboration between the armor (armor) and the weapon (weapon) through a method called usefulFunctionWithWeapon to illustrate that the objects can be related to each other. The most important thing to note is that the collaborator parameter is of the abstract class Weapon, rather than working with concrete classes.

import { Weapon } from "../weapons/weapon.interface";

export interface Armor {
  usefulFunction(): string;
  usefulFunctionWithWeapon(collaborator: Weapon): string;
}

The specific armors that we need for our problem are BodyArmor,OrcArmor and Cloak that will be created by each of the object families according to the Hero's race.

import { Armor } from "./armor-interface";
import { Weapon } from "../weapons/weapon.interface";

export class BodyArmor implements Armor {
  public usefulFunction(): string {
    return "The result of the BodyArmor";
  }

  public usefulFunctionWithWeapon(collaborator: Weapon): string {
    const result = collaborator.usefulFunction();
    return `The result of the BodyAmor collaborating with the (${result})`;
  }
}

import { Armor } from "./armor-interface";
import { Weapon } from "../weapons/weapon.interface";

export class OrcArmor implements Armor {
  public usefulFunction(): string {
    return "The result of the OrcArmor";
  }

  public usefulFunctionWithWeapon(collaborator: Weapon): string {
    const result = collaborator.usefulFunction();
    return `The result of the OrcAmor collaborating with the (${result})`;
  }
}

import { Armor } from "./armor-interface";
import { Weapon } from "../weapons/weapon.interface";

export class Cloak implements Armor {
  public usefulFunction(): string {
    return "The result of the Cloak";
  }

  public usefulFunctionWithWeapon(collaborator: Weapon): string {
    const result = collaborator.usefulFunction();
    return `The result of the Cloak collaborating with the (${result})`;
  }
}

Up to this point, the specific products that we want to create in our video game have been defined but the creation rules have not been established. It is the specific factories that will be in charge of creating the specific products according to the Hero's race. The first class to define is the abstract class AbstractFactory which defines the createWeapon and createAmor methods that are responsible for creating the abstract Weapon and Armor products. Notice that all the code up to this point has made use of abstract classes.

import { Armor } from "./armor/armor-interface";
import { Weapon } from "./weapons/weapon.interface";

export interface AbstractFactory {
  createWeapon(): Weapon;
  createArmor(): Armor;
}

At this time, we have to implement the concrete factories HumanFactory, OrcFactory and MageFactory in which the creator methods are implemented with the concrete products based on the race of the hero.

import { AbstractFactory } from "./abstract-factory";
import { Armor } from "./armor/armor-interface";
import { BodyArmor } from "./armor/body-armor.model";
import { Sword } from "./weapons/sword.model";
import { Weapon } from "./weapons/weapon.interface";

export class WarriorFactory implements AbstractFactory {
  public createWeapon(): Weapon {
    return new Sword();
  }

  public createArmor(): Armor {
    return new BodyArmor();
  }
}

import { AbstractFactory } from "./abstract-factory";
import { Armor } from "./armor/armor-interface";
import { Axe } from "./weapons/axe.model";
import { OrcArmor } from "./armor/orc-armor.model";
import { Weapon } from "./weapons/weapon.interface";

export class OrcFactory implements AbstractFactory {
  public createWeapon(): Weapon {
    return new Axe();
  }

  public createArmor(): Armor {
    return new OrcArmor();
  }
}

import { AbstractFactory } from "./abstract-factory";
import { Armor } from "./armor/armor-interface";
import { Cloak } from "./armor/cloak.model";
import { MageFireball } from "./weapons/mage-fireball.model";
import { Weapon } from "./weapons/weapon.interface";

export class MageFactory implements AbstractFactory {
  public createWeapon(): Weapon {
    return new MageFireball();
  }

  public createArmor(): Armor {
    return new Cloak();
  }
}

To conclude the example of creating the equipment of our heroes, we are going to implement the Client/Context class.

import { AbstractFactory } from "./abstract-factory";
import { MageFactory } from "./mage-factory";
import { OrcFactory } from "./orc-factory";
import { WarriorFactory } from "./warrior-factory";

function clientCode(factory: AbstractFactory) {
  const sword = factory.createWeapon();
  const armor = factory.createArmor();

  console.log(armor.usefulFunction());
  console.log(armor.usefulFunctionWithWeapon(sword));
}

console.log("Client: WarriorFactory");
clientCode(new WarriorFactory());

console.log("----------------");

console.log("Client: OrcFactory");
clientCode(new OrcFactory());

console.log("----------------");

console.log("Client: MageFactory");
clientCode(new MageFactory());

Finally, I’ve created two npm scripts, through which the code presented in this article can be executed:

    npm run example1
    npm run example2

GitHub Repo available here.

Conclusion

Abstract Factory is a design pattern that allows respecting the Open-Closed Principle principle and delegates the responsibility for creating objects to specific classes (concrete factories) using polymorphism. This allows us to have a much cleaner and more scalable code.

This pattern solves the problem that arises when it is necessary to create different types of objects that depend on the interaction of a client with the system in which it is not known beforehand which object the client will create. Furthermore, these objects are related by object families, in such a way that it allows to have them separated by context or object types when using different factories.

Another advantage of this pattern is that the system is not coupled to a set of concrete classes, but the client only communicates with abstract classes allowing to have a much more maintainable code when the software scales.

Finally, the most important thing about this pattern is not the concrete implementation of it, but being able to recognize the problem that this pattern can solve, and when it can be applied. The specific implementation is the least of it, since it will vary depending on the programming language used.

In this series, we are going to show the EcmaScript features from 2015 to today.

• ES2015 aka ES6
• ES2016 aka ES7
• ES2017 aka ES8
• ES2018 aka ES9
• ES2019 aka ES10
• ES2020 aka ES11
• ES2021 aka ES12

Introduction

ES2021 is the version of ECMAScript corresponding to the year 2021. This version doesn’t include as many new features as those that appeared in ES6 (2015). However, some useful features have been incorporated.

This article introduces the features provided by ES2021 in easy code examples. In this way, you can quickly understand the new features without the need for a complex explanation.

Of course, it’s necessary to have a basic knowledge of JavaScript to fully understand the best ones introduced.

The new JavaScript features in ES2021 are:

➡️ String.prototype.replaceAll
➡️ Promise.any
➡️ WeakRef
➡️ Logical Assignment Operators
➡️ Numeric separators

String.protype.replaceAll

Currently there is no way to replace all instances of a substring in a string without use of a global regexp (/regexp/g).

const fruits = '🍎+🍐+🍓+';
const fruitsWithBanana = fruits.replace(/\+/g, '🍌');
console.log(fruitsWithBanana); //🍎🍌🍐🍌🍓🍌

A new replaceAll method has been added to the String prototype.

const fruits = '🍎+🍐+🍓+';
const fruitsWithBanana = fruits.replaceAll('+', '🍌');
console.log(fruitsWithBanana); //🍎🍌🍐🍌🍓🍌

Promise.any

Promise.any gives you a signal as soon as one of the promises fulfills. This is similar to Pormise.race , except any doesn’t reject early when one of the promises rejects.

const myFetch = url => setTimeout(() => fetch(url), Math.floor(Math.random() * 3000));

const promises = [
   myFetch('/endpoint-1'),
   myFetch('/endpoint-2'),
   myFetch('/endpoint-3'),
];

// Using .then .catch
Promise.any(promises) // Any of the promises was fulfilled.
       .then(console.log) // e.g. '3'
       .catch(console.error); //All of the promises were rejected.

// Using async-await
try {
   const first = await Promise.any(promises); // Any of the promises was fulfilled.
   console.log(first);
}catch (error) { // All of the promises were rejected
   console.log(error);
}

WeakRef

The WeakRef proposal encompasses two major new pieces of functionality:

1. creating weak references to objects with the WeakRef class.

2. running user-defined finalizers after objects are garbage-collected, with the FinalizationRegistry class.

These interfaces can be used independently or together, depending on the use case

A WeakRef object contains a weak reference to an object, which is called its target or referent. **A weak reference to an object is a reference that does not prevent the object from being reclaimed by the garbage collector.

A primary use for weak references is to implement caches or mappings holding large objects, where it’s desired that a large object is not kept alive solely because it appears in a cache or mapping.

function toogle(element) {
   **const weakElement = new WeakRef(element);** 
   let intervalId = null;
     
   function toggle() { 
     **const el = weakElement.deref();**
     if (!el) {
        return clearInterval(intervalId);
    }
    const decoration = weakElement.style.textDecoration;
    const style= decoration === 'none' ? 'underline' : 'none';
    decoration = style;
   }
   intervalId = setInterval(toggle, 1000);
 }

 const element = document.getElementById("link");

 toogle(element);
 setTimeout(() => element.remove(), 10000);

FinalizationRegistry provides a way to request that a cleanup callback (finalizers) get called at some point when an object registered with the registry has been reclaimed (garbage-collected).

You create the registry passing in the callback:

const registry = new FinalizationRegistry(heldValue => {
  // ....
});

Then you register any objects you want a cleanup callback for by calling the register method, passing in the object and a held value for it:

registry.register(theObject, "some value");

Logical Assignment Operators

Logical assignment operators combine logical operators and assignment expressions. There are two new operators:

1. Or Or Equals.
2. And And Equals.

// Or Or Equals
|   a   |   b   | a ||= b | a (after operation) |
| true  | true  |   true  |        true         |
| true  | false |   true  |        true         |
| false | true  |   true  |        true         |
| false | false |   false |        false        |

a ||= b
// Equivalent to:
a || (a = b);

// And And Equals
|   a   |   b   | a ||= b | a (after operation) |
| true  | true  |   true  |        true         |
| true  | false |   false |        false        |
| false | true  |   false |        false        |
| false | false |   false |        false        |

a &&= b
// Equivalent to:
a && (a = b);

Numeric separators

This feature allows that numeric literals will be more readable using a visual separation between groups of digits.

Using underscores (_, U+005F) as separators helps improve readability for numeric literals:

1_000_000_000           // A billion
101_475_938.38          // Hundreds of millions

const amount = 12345_00;  // 12,345 (1234500 cents, apparently)
const amount = 123_4500;  // 123.45 (4-fixed financial)
const amount = 1_234_500; // 1,234,500

0.000_001 // 1 millionth
1e10_000  // 10^10000 -- granted, far less useful / in-range...
    
const binary_literals = 0b1010_0001_1000_0101;
const hex_literals = 0xA0_B0_C0;
const bigInt_literals = 1_000_000_000_000n;
const octal_literal = 0o1234_5670;

Conclusion

JavaScript is a live language, and that’s something very healthy for web development. Since the appearance of ES6 in 2015, we’re living a vibrant evolution in the language. In this post, we’ve reviewed the features that arise in ES2021.

Although many of these features may not be essential for the development of your web application, they’re giving possibilities that could be achieved before with tricks or a lot of verbosity.

There are 23 classic design patterns which are described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Factory-Method Pattern works and when it should be applied.

Factory-Method: Basic Idea

The factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method — either specified in an interface and implemented by child classes, or implemented in a base class and optionally overridden by derived classes — rather than by calling a constructor — Wikipedia

Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses — Design Patterns: Elements of Reusable Object-Oriented Software

On many occasions we need to create different types of objects that are not known a priori from a list of possible objects. The natural tendency is to create a factoryManager class that allows us to obtain the different types of objects based on a parameter. However, this solution has two serious drawbacks that we will describe throughout this article:

1. It breaks the principle of Open-Closed Principle which leads to code that is not clean; and that it is not easy to maintain when the software scales.

2. The factoryManager class is attached to all types of objects that you want to build, creating code known as spaghetti code.

The following code shows the classic problem in which there is a create method that returns an object of a type based on a parameter pass as an argument:

function create(type) {
  switch(type){
    case '0': return new Object1();
    case '1': return new Object2();
    case '2': return new Object3();
    default: return new Object4();
  }
}

The Factory-Method pattern allows for clearer code, since it avoids the problem raised above. The UML diagram of this pattern is as follows:

The classes that make up this pattern are the following:

• Product it is the common interface of all objects that can be created.

• ConcreteProductOne and ConcreteProductTwo are implementations of the Product interface.

• Creator is an abstract class in which the factoryMethod method is declared, which will be responsible for generating an object of type Product. The concrete implementation of the object is not carried out by this class, but responsibility is delegated to the ConcreteCreator1 and ConcreteCreator2 classes.

• ConcreteCreator1 and ConcreteCreator2 override the factoryMethod with the creation of the concrete object.

It is important to clarify several points that are often misunderstood as a result of the name of this pattern:

1. This pattern does not implement a factory method that is responsible for creating specific objects. Rather, the responsibility is delegated to the subclasses that implement the abstract class.

2. This pattern is a specific case of the [Template-Method pattern] (/design-patterns-template-method/), in which it delegates the responsibility of variants in an algorithm to concrete classes. In the case of the Factory-Method pattern, the responsibility of creating objects is being delegated to the classes that implement the interface.

3. The factoryMethod method does not have to create new instances every time, but can return these objects from a memory cache, local storage, etc. What is important is that this method must return an object that implements the Product interface.

Factory-Method Pattern: When To Use

1. The problem solved by the pattern Factory-Method is easy to identify: The object with which the client must work is not known a priori, but this knowledge depends directly on the interaction of another user with the system (end-user or system). The traditional example where the need for this pattern arises is when the user selects an object type from a list of options.

2. In the event that it is necessary to extend the internal components (the number of objects that are created) without the need to have the code attached, but instead there is an interface that must be implemented and it should only be extended by creating a class relative to the new object to be included and its specific creator.

Factory-Method Pattern: Advantages and Disadvantages

The Factory-Method pattern has a number of advantages that can be summarized in the following points:

• The code is more maintainable because it is less coupled between the client classes and their dependencies.

• Clean code since the Open-Closed Principle is guaranteed due to new concrete classes of Product can be introduced without having to break the existing code.

• Cleaner code since the Single Responsibility Principle (SRP) is respected because the responsibility of creating the concrete Product is transferred to the concrete creator class instead of the client class having this responsibility.

However, the main drawback of the factory-method pattern is the increased complexity in the code and the increased number of classes required. This a well-known disadvantage when applying design patterns — the price that must be paid to gain abstraction in the code.

Factory-Method pattern examples

Next we are going to illustrate two examples of application of the Factory-Method pattern:

1. Basic structure of the Factory-Method pattern. In this example, we'll translate the theoretical UML diagram into TypeScript code in order to identify each of the classes involved in the pattern.

2. A Point of Service (POS) of a fast food restaurant in which the Factory-Method pattern will be incorrectly applied resulting in a software pattern (not by design) known as Simple-Factory in which the Open-Closed Principle is not respected. However, this programming technique is really useful when no more abstraction is required than necessary. Although, the price to pay is high when you want to scale the project.

3. Resolution of the previous problem applying the Factory-Method pattern.

The following examples will show the implementation of this pattern using TypeScript. We have chosen TypeScript to carry out this implementation rather than JavaScript — the latter lacks interfaces or abstract classes so the responsibility of implementing both the interface and the abstract class would fall on the developer.

Example 1: Basic Structure of the Factory-Method Pattern

In this first example, we’re going to translate the theoretical UML diagram into TypeScript to test the potential of this pattern. This is the diagram to be implemented:

First of all, we are going to define the interface (Product) of our problem. As it is an interface, all the methods that must be implemented in all the specific products (ConcreteProduct1 and ConcreteProduct2) are defined. Therefore, the Product interface in our problem is quite simple, as shown below:

export interface Product {
  operation(): string;
}

The objects that we want to build in our problem must implement the previously defined interface. Therefore, concrete classes ConcreteProduct1 and ConcreteProduct2 are created which satisfy the Product interface and implement the operation method.

import { Product } from "./product.interface";

export class ConcreteProduct1 implements Product {
  public operation(): string {
    return "ConcreteProduct1: Operation";
  }
}

import { Product } from "./product.interface";

export class ConcreteProduct2 implements Product {
  public operation(): string {
    return "ConcreteProduct2: Operation";
  }
}

The next step is to define the Creator abstract class in which an abstract factoryMethod must be defined, which is the one that will be delegated to the concrete classes for the creation of an instance of a concrete object. The really important thing is that it must return an object of the Product class.

On the other hand, the operation method has been defined which makes use of the factoryMethod abstract method. The factoryMethod method that is executed will be that of the concrete class in which it is defined.

import { Product } from "./product.interface";

export abstract class Creator {
  protected abstract factoryMethod(): Product;

  public operation(): string {
    const product = this.factoryMethod();
    return `Creator: ${product.operation()}`;
  }
}

The classes responsible for creating concrete objects are called ConcreteCreator. Each of the ConcreteCreator classes implement the factoryMethod method in which a new object of the ConcreteProduct1 or ConcreteProduct2 class is created depending on the creator class that has been used.

import { ConcreteProduct1 } from "./concrete-product1";
import { Creator } from "./creator";
import { Product } from "./product.interface";

export class ConcreteCreator1 extends Creator {
  protected factoryMethod(): Product {
    return new ConcreteProduct1();
  }
}

import { ConcreteProduct2 } from "./concrete-product2";
import { Creator } from "./creator";
import { Product } from "./product.interface";

export class ConcreteCreator2 extends Creator {
  protected factoryMethod(): Product {
    return new ConcreteProduct2();
  }
}

Finally, we would see how the class Client or Context can select which objects created without prior knowledge, and how this pattern keeps the Open-Closed Principle (OCP).

import { ConcreteCreator1 } from "./concrete-creator1";
import { ConcreteCreator2 } from "./concrete-creator2";
import { Creator } from "./creator";

function client(creator: Creator) {
  console.log(`Client: I'm not aware of the creator's class`);
  console.log(creator.operation());
}

const concreteCreator1 = new ConcreteCreator1();
const concreteCreator2 = new ConcreteCreator2();

client(concreteCreator1);

console.log("----------");

client(concreteCreator2);

Example 2 - POS of a Restaurant (Simple-Factory)

In this example, a solution will be developed that does not satisfy the Factory-Method pattern but uses a FactoryManager class that is responsible for building any object. This solution breaks with the Open-Closed Principle, in addition to having spaghetti code in the creation of objects. The interesting thing is that this same example is refactored into the following example using the factory-method pattern.

The solution proposed here is not a design pattern, but it is a solution that is widely used in the industry. In fact, it has been called Simple Factory and has serious problems as the application scales.

The application to be built is a simple application that allows you to create different types of objects: Pizza, Burger or Kebab.

The creation of these objects is not known a priori and depends on user interaction. The ProductManager class is in charge of building an object of a certain class through the createProduct method.

Below is the UML diagram of this first proposal. A priori the two problems of this solution are already observed:

1. High coupling of the ProductManager class with the system.

2. Spaghetti code in the createProduct method of the ProductManager class which is built with a switch-case that breaks the Open-Closed Principle when you want to extend to other types of products.

As in other examples, we will gradually show the code for the implementation of this solution. The Product interface is exactly the same as the one used in the solution proposed by the Factory-Method pattern.

export interface Product {
  operation(): string;
}

The next step consists of the implementation of each of the specific objects that you want to create in this problem: Burger, Kebab and Pizza.

import { Product } from "./product.interface";

export class Burger implements Product {
  public operation(): string {
    return "Burger: Results";
  }
}

import { Product } from "./product.interface";

export class Kebab implements Product {
    public operation(): string {
        return 'Kebab: Operation';
    }
}

import { Product } from "./product.interface";

export class Pizza implements Product {
    public operation(): string {
        return 'Pizza: Operation';
    }
}

Finally, we implement the ProductManager class, which is responsible for creating each of the object types based on the type parameter. An enum type has been used that allows us to avoid using strings in the use of the switch-case statement.

import { Burger } from "./burger.model";
import { Kebab } from "./kebab.model";
import { PRODUCT_TYPE } from "./product-type.enum";
import { Pizza } from "./pizza.model";

export class ProductManager {
  constructor() {}
  createProduct(type): Product {
    switch (type) {
      case PRODUCT_TYPE.PIZZA:
        return new Pizza();
      case PRODUCT_TYPE.KEBAB:
        return new Kebab();
      case PRODUCT_TYPE.BURGER:
        return new Burger();
      default:
        throw new Error("Error: Product invalid!");
    }
  }
}

Finally, it would be necessary to show the Client or Context class that makes use of the productManager class. Apparently from the Client class it is not observed that under this class there is a strongly coupled code that violates the principles of clean code.

import { PRODUCT_TYPE } from "./product-type.enum";
import { ProductManager } from "./product-manager";

const productManager = new ProductManager();

const burger = productManager.createProduct(PRODUCT_TYPE.BURGER);
const pizza = productManager.createProduct(PRODUCT_TYPE.PIZZA);
const kebab = productManager.createProduct(PRODUCT_TYPE.KEBAB);

console.log(burger.operation());
console.log(pizza.operation());
console.log(kebab.operation());

Example 3 - POS of a Restaurant using Factory-Method

In this example, we are going to take up the problem posed in Example 2 (POS of a restaurant) to propose the solution using the factory-method pattern. The objective of this solution is to avoid the spaghetti code that has been generated in the productManager class and to allow respecting the Open-Closed Principle.

Therefore, following the same methodology as the one we have presented in the previous examples, we are going to start by looking at the UML diagram that will help us identify each of the parts of this pattern.

In this case, the objects that we want to build would be those corresponding to the Pizza, Burger and Kebab classes. These classes implement the Product interface. All this part of code is identical to the one presented in the previous example. However, let's review the code to keep it in mind:

export interface Product {
   operation(): string;
}

import { Product } from "./product.interface";

export class Burger implements Product {
  public operation(): string {
    return "Burger: Results";
  }
}

import { Product } from "./product.interface";

export class Kebab implements Product {
    public operation(): string {
        return 'Kebab: Operation';
    }
}

import { Product } from "./product.interface";

export class Pizza implements Product {
    public operation(): string {
        return 'Pizza: Operation';
    }
}

On the other side of the UML diagram, we can find the creator classes. Let's start by reviewing the Creator class, which is responsible for defining the factoryMethod method, which must return an object that implements the Product interface. In addition, we will have the someOperation method which makes use of the factoryMethod abstract method which is developed in each of the concrete creator classes.

import { Product } from "./product.interface";

export abstract class Creator {

    public abstract factoryMethod(): Product;

    public someOperation(): string {
        const product = this.factoryMethod();
        return `Creator: The same creator's code has just worked with ${product.operation()}`;
    }
}

We would still have to define each of the specific BurgerCreator, KebabCreator and PizzaCreator creator classes that will create each of the specific objects (NOTE: remember that it is not necessary to always create an object, if we had a structure of data from which instances that were cached were retrieved, the pattern would also be implemented).

import { Creator } from "./creator";
import { Kebab } from "./kebab.model";
import { Product } from "./product.interface";

export class KebabCreator extends Creator {
    public factoryMethod(): Product {
        return new Kebab();
    }
}

import { Creator } from "./creator";
import { Pizza } from "./pizza.model";
import { Product } from "./product.interface";

export class PizzaCreator extends Creator {
    public factoryMethod(): Product {
        return new Pizza();
    }
}

import { Burger } from "./burger.model";
import { Creator } from "./creator";
import { Product } from "./product.interface";

export class BurgerCreator extends Creator {
  public factoryMethod(): Product {
    return new Burger();
  }
}

The last step we would have to complete our example would be to apply the pattern that we have developed using it from the Client or Context class. It is important to note that the Client function does not require any knowledge of the Creator or the type of object to be created. Allowing to fully delegate responsibility to specific classes.

import { BurgerCreator } from "./burger-creator";
import { Creator } from "./creator";
import { KebabCreator } from "./kebab-creator";
import { PizzaCreator } from "./pizza-creator";

function client(creator: Creator) {
    console.log('Client: I\'m not aware of the creator\'s class, but it still works.');
    console.log(creator.someOperation());
}

const pizzaCreator = new PizzaCreator();
const burgerCreator = new BurgerCreator();
const kebabCreator = new KebabCreator();


console.log('App: Launched with the PizzaCreator');
client(pizzaCreator);

console.log('----------');

console.log('App: Launched with the BurgerCreator');
client(burgerCreator);

Finally, I have created three npm scripts through which the code presented in this article can be executed:

npm run example1
npm run example2
npm run example3

GitHub Repo: https://github.com/Caballerog/blog/tree/master/factory-method-pattern

Conclusion

Factoy-Method is a design pattern that allows respecting the Open-Closed Principle and delegates the responsibility for creating objects to specific classes using polymorphism. This allows us to have a much cleaner and more scalable code. It mainly solves the problem that arises when it is necessary to create different types of objects that depend on the interaction of a client with the system, and that it is not known a priori which object the client will create.

Finally, the most important thing about this pattern is not the specific implementation of it, but being able to recognize the problem that this pattern can solve, and when it can be applied. The specific implementation is the least of it since that will vary depending on the programming language used.

There are 23 classic design patterns which are described in the original book Design Patterns: Elements of Reusable Object-Oriented Software. These patterns provide solutions to particular problems often repeated in software development.

In this article, I am going to describe how the Builder Pattern works and when it should be applied.

Builder Pattern: Basic Idea

The builder pattern is a design pattern designed to provide a flexible solution to various object creation problems in object-oriented programming. The intent of the Builder design pattern is to separate the construction of a complex object from its representation — Wikipedia

Separate the construction of a complex object from its representation so that the same construction process can create different representations — Design Patterns: Elements of Reusable Object-Oriented Software

On many occasions, the constructors of a class have a long list of arguments that have no semantic value, or that are not used by all instances of that class. This causes constructors to have a long list of arguments or having to define many constructors with different parameters, causing an explosion of constructor methods in the class.

The following code shows the classic problem in which there is a constructor with a list of parameters that must be initialized, even though the object in question does not require to have values in some of its attributes.

    new User('carlos', 'Caballero', 26, true, true, false, null, null);

The Builder pattern allows us to write clearer code, since it avoids the problem posed above. The UML diagram of this pattern is as follows:

The classes that make up this pattern are the following:

• Product is the concrete result of a construction process. That is, they will be the models of our application.

• Builder is a common interface for the concrete builders.

• ConcreteBuilder are different implementations of the constructive process. These classes will be responsible for clarifying the differences in the business logic of each of the object construction processes.

These classes will be responsible for clarifying the differences between the business logic of each of the object construction processes.

• Director defines the order in which the construction steps are performed. Its purpose is the reusability of specific configurations. The Director can be omitted in some implementations of this pattern, although its use is highly recommended, since it abstracts the client from the concrete steps of construction to the client.

• Client is the class that uses the pattern. There are two possibilities:

1 - The client uses the ConcreteBuilder, executing the construction steps one by one.

2 - The client uses the Director which implements each of the construction processes, and acts as an intermediary between the Client and the ConcreteBuilder classes.

Builder Pattern: When To Use

1. The problem solved by the Builder pattern is easy to identify: this pattern should be used when it is necessary to use a constructor with a very long parameter list or when there is a long list of constructors with different parameters.

2. When it is necessary to build different representations of the same object. That is, when objects of the same class with different characteristics are needed.

Builder Pattern: Advantages and disadvantages

The Builder pattern has a number of advantages that can be summarized in the following points:

• Objects can be created step by step.

• The creation of an object can be postponed until all the necessary information for the construction of the same is available. The object will not be obtained until the build method of the Builder class is executed.

• Clean code: The Single Responsibility Principle (SRP) is applied, since the complex construction of the object is isolated from the business logic of this object.

However, the main drawback of the builder pattern is the increased complexity in the code, and the increased number of classes required. This a well known disadvantage when applying design patterns, since this is the price that must be paid in order to gain abstraction in the code.

Next we are going to illustrate three examples of application of the Builder pattern:

1. Basic structure of the Builder pattern. In this example we are going to translate the theoretical UML diagram into TypeScript code in order to identify each of the classes involved in the pattern.

2. Creation of characters in a video game. Let’s think of the classic WoW (World of Warcraft) scenario in which the player can select between two races: Humans and Orcs.

3. Creation of products (Burgers) in a Point Of Sale (POS).

The following examples will show the implementation of this pattern using TypeScript. We have chosen TypeScript to carry out this implementation rather than JavaScript, since the latter lacks interfaces or abstract classes and therefore, the responsibility of implementing both the interface and the abstract class would fall on the developer.

Example 1 — Basic structure of the Builder pattern

In this first example we are going to translate the theoretical UML diagram into TypeScript code to test the potential of this pattern. The diagram to be implemented is the following:

First we are going to define the model (Product) of our problem. In this class it is modeled that we will have a list of parts that is simply a list of strings . For this we define the classic addPart, removePart and showParts methods to manage this attribute.

However, note that the constructor of the object does not receive the list of initial parameters (in TypeScript it is not necessary to define it), but the model attribute will be modified through methods.

export class Product {
   public parts: string[] = [];

   public addPart(part: string): void {
       this.parts.push(part);
   }
   public removePart(part: string): void {
       this.parts = this.parts.filter(_part => _part !== part);
   }

   public showParts(): void {
       console.log(`Product parts: ${this.parts.join(', ')}\n`);
   }
}

The next step is to create the builder interface that defines the concrete builders. In the builder, the operations to add and remove each of the parts (A, B and C) are defined.

export interface Builder {
    addPartA(): void;
    addPartB(): void;
    addPartC(): void;
    removePartA(): void;
    removePartB(): void;
    removePartC(): void;
}

The concrete builder class has a private object of the class that we want to build (Product). The necessary modifications will be applied to its attributes to build the object according to each case.

Note that what the constructor method does is initialize the product, and that there is a build method that this is responsible of returning the object that has been configured in the ConcreteBuilder1 class and reset the internal object to be able to build another object. The ConcreteBuilder1 class configures a concrete object until the build method is invoked.

Note that what the constructor method does is initialize the product, and that there is a build method that is responsible of returning the object that has been configured in the ConcreteBuilder1 class and resetting the internal object to be able to build another object. The ConcreteBuilder1 class configures a concrete object until the build method is invoked.

import { Builder } from "./builder.interface";
import { Product } from "./product";

export class ConcreteBuilder1 implements Builder {
    private product: Product;

    constructor() {
        this.reset();
    }

    public reset(): void {
        this.product = new Product();
    }

    /**
     * Steps
     */
    public addPartA(): void {
        this.product.addPart('PartA1');
    }

    public addPartB(): void {
        this.product.addPart('PartB1');
    }

    public addPartC(): void {
        this.product.addPart('PartC1');
    }

    public removePartA(): void {
        this.product.removePart('PartA1');
    }

    public removePartB(): void {
        this.product.removePart('PartB1');
    }

    public removePartC(): void {
        this.product.removePart('PartC1');
    }

    public build(): Product {
        const result = this.product;
        this.reset();
        return result;
    }
}

Once we have the concrete operations to build an object through the ConcreteBuild1 class, the next step is to define concrete steps to perform different constructions. The Director class is responsible for defining methods that specify the construction steps using the Builder object.

Therefore, the Director class receives an object from the Builder class as a parameter (in this case it would be BuilderConcrete1) and several constructions are defined:

1. BasicObject → It only consists of part A.

2. FullObject → It consists of parts A, B and C.

import { Builder } from "./builder.interface";

export class Director {
    private builder: Builder;

    public setBuilder(builder: Builder): void {
        this.builder = builder;
    }

    public buildBasicObject(): void {
        this.builder.addPartA();
    }

    public buildFullObject(): void {
        this.builder.addPartA();
        this.builder.addPartB();
        this.builder.addPartC();
    }
}

Finally, it would be necessary to define the Client or Context class that makes use of the pattern. This client is quite clean since you only define the Builder object that you want to use and the creation of objects is invoked through the Director.

import { ConcreteBuilder1 } from './concrete-builder1';
import { Director } from './director';

function client(director: Director) {
    const builder = new ConcreteBuilder1();
    director.setBuilder(builder);

    console.log('A preconfigured basic object:');
    director.buildBasicObject();
    builder.build().showParts();

    console.log('A preconfigured full object:');
    director.buildFullObject();
    builder.build().showParts();

    // A custom object can be create without a Director class.
    console.log('Custom product:');
    builder.addPartA();
    builder.addPartC();
    builder.build().showParts();
}

const director = new Director();
client(director);

Example 2 — Creation of Heroes of a video game

Once the classic theoretical example has been presented to understand the responsibilities of each of the classes of the pattern, we are going to present another example in which we identify each of these classes with a specific problem.

Our problem is the representation of different heroes or characters in a video game. We will focus on the classic WoW (World of Warcraft) game, in which the heroes can be divided into two races: Humans and Orcs. In addition, each of these heroes can have armor, weapon or different skills depending on whether the hero is human or orc.

In the event that the Builder pattern is not applied, it causes a constructor to be defined in the Hero class with a long list of parameters (race, armor, skills...), which in turn, cause logic to be defined in the constructor to decide if the armor is human or orc. So, with this initial solution the problem is coupled since any change in the business logic would make rewriting quite a few pieces of code, with hardly any possibility of reuse.

In the event that the Builder pattern is not applied, it causes a constructor to be defined in the Hero class with a long list of parameters (race, armor, skills...), which in turn, causes logic to be defined in the constructor to decide whether the armor is human or orc. With this initial solution the problem is coupled, since any change in the business logic would require rewriting quite a few pieces of code, with hardly any possibility of reuse.

Therefore, the first thing we have to do is stop and think about how the Builder pattern helps us solve this problem. So, we focus on showing the UML diagram that solves this problem and we begin to implement it.

In this example we are going to follow the same order as in the previous example and we are going to start with the model or object that we want to build flexibly.

The Hero class defines the race, armor, weapon and skills properties which in our example for simplicity are simple character strings. All these attributes could be objects but to simplify the example we have left them as character strings.

export class Hero {
    public race: string;
    public armor: string;
    public weapon: string;
    public skills: string[];

    	
   public toString(): string {
        return `Hero:
                   race=${this.race ? this.race : 'empty'}
                   armor=${this.armor ? this.armor: 'empty'}
                   weapon=${this.weapon ? this.weapon: 'empty'}
                   skills=${this.skills ? this.skills: 'empty'}
                 `;
	}
}

The HeroBuilder interface defines the methods that the specific builders will have. Let’s observe that we will have the Hero object that will be configured little by little, each of the methods that allows the configuration of the object: setArmor, setWeapon and setSkills; and finally we will have the build method that finishes the configuration of the object and extracts the Hero object.

import { Hero } from "./hero.model";

export abstract class HeroBuilder {
	protected hero: Hero;
	
	public abstract setArmor(): void;
  	public abstract setWeapon(): void;
  	public abstract setSkills(): void;

	public abstract build(): Hero;
}

Once the builder is defined (as an abstract class or interface) we must build the two specific builders that our problem requires: HumanHeroBuilder and OrcHeroBuilder. In the demo code we have completed with a different string according to each builder. It is important to note that the build method of each of the builders will return the built object (Hero) and reset the state of the object to be able to build another object.

import { Hero } from "./hero.model";
import { HeroBuilder } from "./hero-builder";

export class HumanHeroBuilder extends HeroBuilder {
   
    constructor() {
    	super();
        this.reset();
    }
	
    public reset() {
      	this.hero = new Hero();
        this.hero.race = "Human";
    }
    
    public setArmor():void {
        this.hero.armor = "Human armor";
    }
    
    public setWeapon(): void {
      	this.hero.weapon = 'Human weapon';
    }

    public setSkills(): void {
      	this.hero.skills = ['Human skill1', 'Human skill2'];
    }

    public build(): Hero {
      	const hero = this.hero;
      	this.reset();
      	return hero;
    }
}

import { Hero } from "./hero.model";
import { HeroBuilder } from "./hero-builder";

export class OrcHeroBuilder extends HeroBuilder {
   
    constructor() {
    	super();
        this.reset();
    }

    public reset() {
     	this.hero = new Hero();
        this.hero.race = "Orc";
    }
    
    public setArmor():void {
        this.hero.armor = "Orc armor";
    }
    
    public setWeapon(): void {
      	this.hero.weapon = 'Orc weapon';
    }

    public setSkills(): void {
      	this.hero.skills = ['Orc skill1', 'Orc skill2'];
    }

    public build(): Hero {
      	const hero = this.hero;
      	this.reset();
      	return hero;
    }
}

The last element of the pattern would be the Hero-Director class that allows you to store configurations that are repeated throughout the code. In our example we have created three Hero creation setups. For example, the createHero method builds a complete hero, that is, it assigns armor, abilities and weapons. In addition, we create a hero without any equipment through the createHeroBasic method and, finally, to illustrate another configuration, the createHeroWithArmor method is defined, which returns a hero in which only the armor has been assigned.

import { HeroBuilder } from "./hero-builder";

export class HeroDirector {

    public createHero (heroBuilder: HeroBuilder) {
        heroBuilder.setArmor();
        heroBuilder.setSkills();
    	heroBuilder.setWeapon();
    	return heroBuilder.build();
  }
 
  public createHeroBasic (heroBuilder: HeroBuilder){
	return heroBuilder.build();
  }
    
  public createHeroWithArmor(heroBuilder: HeroBuilder){
	heroBuilder.setArmor();
    return heroBuilder.build();
 }

}

Finally, we will show a console client that makes use of the two builders that we have built throughout this example. In this example we create the two builders: HumanHeroBuilder and OrcHeroBuilder; and the director’s class: HeroDirector. As a demonstration, we will use the two builders together with the director to create the three hero configurations that the HeroDirector class has preconfigured.

import { HeroDirector } from "./hero-director";
import { HumanHeroBuilder } from "./human-hero-builder";
import { OrcHeroBuilder } from "./orc-hero-builder";

const humanBuilder = new HumanHeroBuilder();
const orcBuilder = new OrcHeroBuilder();
const heroDirector = new HeroDirector();

const humanHero = heroDirector.createHero(humanBuilder);
const humanHeroWithArmor = heroDirector.createHeroWithArmor(humanBuilder);
const humanHeroBasic = heroDirector.createHeroBasic(humanBuilder);

console.log(humanHero.toString());
console.log(humanHeroWithArmor.toString());
console.log(humanHeroBasic.toString());

const orcHero = heroDirector.createHero(orcBuilder);
const orcHeroWithArmor = heroDirector.createHeroWithArmor(orcBuilder);
const orcHeroBasic = heroDirector.createHeroBasic(orcBuilder);

console.log(orcHero.toString());
console.log(orcHeroWithArmor.toString());
console.log(orcHeroBasic.toString());

Example 3 — Creation of burgers (Point of Sale)

In the following example we are going to create a POS for a burger restaurant. The main change in this example compared to the previous ones is that each modification operation of the object to be created, instead of not returning any value, will return the builder itself. In this way, the different operations to be carried out by the builder itself can be chained, since each operation returns the Builder object.

Following the same methodology that we have presented in the previous examples, we are going to start by looking at the UML diagram that will help us identify each of the parts of this pattern.

In this case, the object we want to build would be the one corresponding to the Burger class where there is a list of ingredients to configure in each of the burgers. The Burger class will have accessor methods corresponding to each of its attributes.

The code associated with this class is the following:

import { BurgerType } from "./burger-type.interface";

export class Burger {
    public type: BurgerType = BurgerType.NORMAL;
    public cheese = false;
    public lettuce = false;
    public tomato = false;
    public double = false;
    public onion = false;
    public pickle = false;
    public bacon = false;
    public chiliSauce = false;
    public egg = false;

    public setType(type: BurgerType){
        this.type = type;
    }

    public setCheese() {
        this.cheese = true;
    }

    public setLettuce() {
        this.lettuce = true;
    }

    public setTomate() {
        this.tomato = true;
    }

    public setDouble() {
        this.double = true;
    }

    public setOnion() {
        this.onion = true;
    }

    public setPickle() {
        this.pickle = true;
    }

    public setBacon() {
       this. bacon = true;
    }

    public setChiliSauce() {
        this.chiliSauce = true;
    }

    public setEgg() {
        this.egg = true;
    }
}

In this example, the BurgerType enumerated type has been included, which allows defining the different types of burgers that exist in the application.

export enum BurgerType {
    NORMAL,
    CHEESE,
    VEGGIE,
    DOUBLE,
    CHEESE_BACON,
    DOTTECH,
    GODZILLA
}

In the BurgerBuilder class, each method performs the modification on the object that is being configured, and also, the builder is being returned to be able to chain the different operations. Of course, the build method still returns the Burger class object.

import { Burger } from "./burger.model";
import { BurgerType } from "./burger-type.interface";

export class BurgerBuilder {
    private burger: Burger;


    public constructor(){
        this.burger = new Burger();
    }

    public setType(type: BurgerType): BurgerBuilder{
        this.burger.setType(type);
        return this;
    }

    public setDouble(): BurgerBuilder{
        this.burger.setDouble();
        return this;
    }

    public addCheese(): BurgerBuilder{
        this.burger.setCheese();
        return this;
    }

    public addLettuce(): BurgerBuilder{
        this.burger.setLettuce();
        return this;
    }

    public addTomato(): BurgerBuilder{
        this.burger.setTomate();
        return this;
    }


    public addOnion(): BurgerBuilder{
        this.burger.setOnion();
        return this;
    }

    public addPickle(): BurgerBuilder{
        this.burger.setPickle();
        return this;
    }

    public addBacon(): BurgerBuilder{
        this.burger.setBacon();
        return this;
    }

    public addChiliSauce(): BurgerBuilder{
        this.burger.setChiliSauce();
        return this;
    }

    public addEgg(): BurgerBuilder{
        this.burger.setEgg();
        return this;
    }

    public build(): Burger{
        return this.burger;
    }
}

The BurgerDirector class is in charge of configuring the operations defined in the BurgerBuilder class. This is where you can see how different types of burgers are configured using the chained methods, which allows for ease of reading the code. It is important to remember that until the build method is executed, the same burger is being configured.

import { Burger } from "./burger.model";
import { BurgerBuilder } from "./burger-builder";
import { BurgerType } from "./burger-type.interface";

export class BurgerDirector {

    public constructor(private builder: BurgerBuilder){
        this.builder = builder;
    }

    public serveRegularBurger(): Burger{
        return this.builder
                    .setType(BurgerType.NORMAL)
                    .build();
    }

    public serveCheeseBurger() : Burger{
        return this.builder
                    .addCheese()
                    .setType(BurgerType.CHEESE)
                    .build();
    }

    public serveVeggieBurger(): Burger{
        return this.builder
                    .addCheese()
                    .addLettuce()
                    .addTomato()
                    .setType(BurgerType.VEGGIE)
                    .build();
    }

    public serverDoubleBurger(): Burger{
        return this.builder.setDouble()
                      .setType(BurgerType.DOUBLE)
                      .build();
    }


    public serveCheeseBaconBurger(): Burger{
        return this.builder.addCheese()
                      .addBacon()
                      .setType(BurgerType.CHEESE_BACON)
                      .build();
    }
}

Finally, we show the client that uses the pattern. In this case, a random number is selected that defines a type of burger and the director is invoked to serve us that burger.

import { Burger } from "./burger.model";
import { BurgerBuilder } from "./burger-builder";
import { BurgerDirector } from "./buger-director";

let burger: Burger;

const burgerType = Math.round(Math.random() * 6);
console.log('BurgerType: ', burgerType);

const burgerBuilder: BurgerBuilder = new BurgerBuilder();
const burgerDirector: BurgerDirector =  new BurgerDirector(burgerBuilder);


switch (burgerType) {
    case 1:
        burger = burgerDirector.serveRegularBurger();
        break;
    case 2:
        burger = burgerDirector.serveCheeseBurger();
        break;
    case 3:
        burger = burgerDirector.serveVeggieBurger();
        break;
    case 4:
        burger = burgerDirector.serverDoubleBurger();
        break;
    case 5:
        burger = burgerDirector.serveCheeseBaconBurger();
        break;
    case 6:
        burger = burgerDirector.serveDotTechBurger();
        break;
    default:
        burger = burgerDirector.serveGozillaBurger();
        break;
}

console.log(burger);

Finally, I have created three npm scripts through which the code presented in this article can be executed:

    npm run example1
    npm run example2
    npm run example3

GitHub Repo: https://github.com/Caballerog/blog/tree/master/builder-pattern

Conclusion

Builder is a design pattern that allows you to avoid having constructors with a long list of parameters in which not always all the parameters are required. It allows you to build instances of a certain object in a more flexible way, since you can configure only the attributes that are strictly necessary.

The code is much cleaner since there will be no parameters in the constructors that are not used, allowing only those parameters that are required to create the object to be used. Furthermore, since there is a Director class for the builders, the object creation configurations are reused so that there is no direct interaction with the Builder classes on the client.

Finally, the most important thing about this pattern is not the specific implementation of it, but being able to recognize the problem that this pattern can solve, and when it can be applied. The specific implementation is the least of it, since it will vary depending on the programming language used.

Introduction

I am often asked which programming language is the ideal one to start learning to program. The answer to that question is very simple, the programming language does not matter but the important thing is logical reasoning and the first contact with a programming paradigm, the rest will go step by step as you immerse yourself in the industry.

However, the truth is that I have encountered many opponents in learning JavaScript because of its notoriety in the industry. It is true that JavaScript was born with a purpose and the industry has placed it by solving problems for which it was not originally intended. This has caused it to have such a bad reputation among veteran developers or those who come from other programming paradigms. But we cannot ignore that JavaScript is a living language, for more than five years (2015) it receives annual updates, it has a large community that is giving it support and reviewing possible improvements.

In this article, I am going to give you reasons why you should learn JavaScript. Apart from the fact that you do not want to dedicate yourself to the frontend, where it is its first execution environment.

1. Most Popular Programming Language In The World

This statement can harm lovers of exotic languages, who improve performance or security compared to other languages but are in the minority. In our case, JavaScript is the most used and popular programming language in the world, which makes it an excellent choice for a newbie.

This happens mainly because in the frontend world (on the Web) there is no other rival language. There is a monopoly of programming languages, in the past, it competed against VisualBasic Script, Action Script (Flash) or even with JAVA Applets. But none of these languages have survived JavaScript. In fact, the only language that nowadays begins to occupy a prominent position on the frontend is TypeScript, which is a JavaScript superset, and therefore, it is highly recommended to previously know how JavaScript works in depth.

2. Javascript Jobs

In any field or software development environment, we find several programming languages that solve the same type of problems. However, we have commented that JavaScript has a “monopoly” on the web application frontend market. That fact already places it in a privileged position compared to other languages. The most interesting thing to find jobs in JavaScript is that all the frontend tools/frameworks today are based on JavaScript, and it is highly recommended to know in depth how JavaScript works. That is, if we want to opt for a job in React, Vue and even Angular (it uses TypeScript as a language) you will need to have a knowledge of JavaScript.

Therefore, learning and understanding JavaScript will allow you to get a good and well-paid job. In fact, there is a big problem in the web development industry that will allow us to get a good job: There is a lack of professionals with solid knowledge in the JavaScript language.

As of this writing (August, 2020) there are almost 40,000 jobs requiring JavaScript (in the US).

Not only is it the number of jobs required, but the average salary: $117,717 per year.

3. It’s Everywhere

When I was a university student, I heard that Java was the revolution because we could write the code only once and it ran on all devices, and it is true that Java managed to abstract us from the operating system with its virtual machine. I felt in love with the idea behind JAVA, and today, we have a much easier and more comfortable “virtual machine” that are Web browsers (FireFox, Edge or Chrome) that execute JavaScript code. Therefore, in all the environments that a Web browser is installed, we will have JavaScript, this means that we can have practically all the devices that an end user can use.

This does not end here, for more than 10 years JavaScript can be executed on servers thanks to nodejs. In fact, this allows us to have code written in JavaScript on small devices without the need for a graphical environment.

4. Beginner-Friendly

Again, I want to talk about my beginnings in Computer Science. When I began to develop software at the age of 11 (approximately) I first learnt the Pascal and C programming languages without tools, without the help of the compiler to know what was happening. In fact, it was quite hard to start learning to develop software and you needed a mentor to guide you a bit on this path.

Today, there are many facilities to start developing software, but JavaScript is a language that allows beginners to start developing software. Of course, this software will not be the best solution to the problem to be solved, but the novice will be writing lines of code and will have started his career in software development.

The next step is to not stop learning, to wonder how to improve and improve day by day, but you will already be in the world of development. That is, JavaScript is a novice friendly language, and this allows new developers to enter.

It is the task of the most veteran developers, to guide the newcomers on the right path of development; and for newbies to listen and learn from the experience of their fellow veterans. But that's another topic that we can discuss at another time.

5. Community

Being unique in the world is something that humans have sought for years. In fact, in the fashion, automotive or jewelry industry it is something that has an extra cost for users.

In our context, being unique or being alone is a danger. Our work is a collaborative one. It is a work in which you have to be totally synchronized with your colleagues and it is where being many is an advantage. That is, if the community of people who use the programming language, create libraries, solve doubts, help keep the language alive with revisions, these are advantages.

Now is when you discover that the size of the community is very important and that the JavaScript community is possibly the largest in the world compared to other languages (I do not have a statistical study of it, but it should be in the Top 3 with almost total certainty).

Some data that can help us deduce that the JavaScript community is one of the largest in the world are the following:

• Largest StackOverflow Community. StackOverflow is the largest platform for programming Q&A, and this is where you can see how the community helps solve problems of other colleagues.

• Largest Meetup Community. Meetup is a platform that allows you to connect people who have the same interest. In terms of programming languages, the number of communities dealing with JavaScript is the largest on the platform (approximately 3,600 and more than 1.5 Million members worldwide).

• Most-tagget language on GitHub. GitHub is the main opensource repository that exists today (acquired by Microsoft). In this platform, JavaScript is the most tagged programming language of all the projects that are hosted on this platform.

Conclusions

This post is not analyzing whether the JavaScript programming language is the best option to solve your problems. Whether it needs to transform or not, but we are looking at why you should learn JavaScript in 2020 and even for years to come.

It is an analysis looking at the positive points for you as a software developer and, of course, perhaps in a few years there will be another language or environment that will replace JavaScript but what you have learned in this language you can transfer to the next.

In my opinion, you should not miss the opportunity to learn JavaScript for its interesting advantages over other languages.

In this posts series different tasks are described that can be automated to perform a deployment of frontend applications in Angular.

Posts Series

• Build & Deploy Angular Apps en GitHub Pages con GitHub
  Actions
• Automatic Adaptive Images in Angular Applications

Introduction

Today, the users access to the Web apps through a wide variety of devices, such as laptops, tablets, smartPhones, desktop computers, etc..., which have different screen sizes and resolutions. On the other hand, one of the principles of accessibility is to get as many users as possible enriching and satisfying the experience in accessing applications overcoming both physical barriers (hearing, visual disabilities, cognitive, etc ...) as well as material or technological. Today, there are users who connect from different devices, as we have already indicated, and also with different technological features such as the bandwidth of internet network.

In addition, there are web applications that have high visual content, and therefore, a lot of images. These images are normally stored on a CDN (Content-Delivery-Network) from which the images are downloaded to the device.

In some specific areas of the world, or circumstances, downloading all these images can mean a bandwidth that is excessive for the users. Similarly, any optimization, even to users who have high performance devices is a benefit since the app will be available sooner.

In this post, we are going to show step by step how to build an Angular application with responsive images for different sizes although it could be for any technology.

Problem to solve

The problem I have solved is the one I have experienced for the open source project Angular-Communities. This project consists of a Google Map in which the shields of the different Angular communities around the world are displayed. Also, on a side-nav we find all the shields of the different communities, so we can navigate and select them for advanced information on those Angular communities. Allow me to tell you, just as an aside, do not hesitate and add your community to this map so that we can all have the information of your community.

In this specific problem, we had,at the date of this post, about 70 communities, each with its personalized shield. Each of these shields is an scalar image in PNG format that can be between 13KiB – 186KiB. The 70 images have a size of 2.6MiB. In this situation, we need to download all the images at the beginning, not being able to perform a technique lazy to download the images. This simplifies the code and the development complexity drastically. However, it seems worrying that all devices, no matter their sizes, have to download 2.6MiB every time that access the website, causing an unnecessary loss of performance.

For this post, I have built a small demo in which all the images from Angular-Communities are downloaded in a single component with the final result of the post.

The following table shows the size of the images according to the format and the image size. It can be seen that the format getting the smallest file size, even with the same image size, is .webp.

Create images of different sizes and formats

Imagine we had to edit each of the images with a software graphic editing, such as Gimp or Photoshop, manually. This would provoke a great amount of time invested just changing the size, quality and format of the images. We might think that doing this task only once for our task it could be a tedious but valid task (still I think that we should not do it manually, being able to do it automatically). However, this task gets more complicated if the images we want to carry out the process to gradually increases by interaction with the users or even if we have to make different adjustments to the sizes and qualities that we want to generate for each of the images.

Therefore, the ideal would be to have a tool/script that allows us to automate this task so that it is only a matter of executing a simple script and all our battery of images is generated automatically.

In our context, we are going to use a tool built using node.js since installing it and using it in our Angular application does not require the installation of new applications or package managers for different programming languages.

The chosen tool is responsive-image-builder (RIB), which is defined as a building pipeline of images in WebP format ultra fast for the Web. The time it will take to generate the images will depend on your processor or the processor of your integration system and the number of images to be transformed.

RIB Features

• ⚡ Fast - Uses the lightning-quick [libvips
• image processing](https://github.com/jcupitt/libvips/wiki/Speed-and-memory-use).
• 🔥 Multithreaded - Scales to all available CPU cores.
• 📦 Zero configuration - Change nothing, change everything. You choose.
• 🌍 Universal - a flexible image build process that doesn't enforce any principles.
• ✂️ Cross-platform - Tested on Windows, macOS and Linux.
• 😊 Friendly experience - telling you what's going on, from start to finish.
• ✨ SVG Tracing - for really fancy placeholders.

All these features make this open-source tool ideal for our purpose. First of all, we install the package as a development dependency.

npm i -D responsive-image-builder

The use of this tool is quite simple since we only have to specify the parameters of the following command:

rib -i <input> -o <output> <options>

Therefore, if we want to include in our deploy pipeline that all the images in a certain directory are transformed and generated in a new directory, we can build the following npm-script that runs just before the deploy task.

"pre:deploy": "rib -i src/assets/images_raw -o src/assets/images --no-clean --force"

Although one of the characteristics of this tool/package is that it does not need configuration, in our specific case we want to build a responsive application in which each screen size has a set of images adjusted to its parameters. In other words, when a user accesses the Web page from a mobile device, they must download images that are the appropriate size for that device, images that are lighter than the ones for large screens, and when accessed from a device with a large screen, laptop or smartTV high resolution images can be enjoyed.

Therefore, we must configure the different sizes of images that we want to automatically generate. This configuration is done by creating a file called .ribrc.json in which an array is specified with the different configurations or image generation formats that you want to generate from each of the original images. Thus, each of the configurations allows you to specify a suffix using the name property, the width of the image using the width property, and that you want to force the creation of the image (it is overwritten if a previous one already exists) with the force property.

Therefore, in our configuration file, we are specifying that we will generate five images from each of the original images that will have the configurations as prefixes: xs, sm, md, lg and xl.

Also, rib generates all images in the original format, .png or .jpg and in the .webp format. So if the browser supports the .webp format, it uses this one instead of the previous ones. The following section shows how you can delegate responsibility for using one image or another to the HTML (using the picture element).

Elemento Picture

HTML5 introduced the <picture> element which allows more flexibility to specify images compared to the <img> element. The most common use of the <picture> element is to delegate responsibility for images in adaptive layouts to the browser via HTML. In other words, instead of scaling large images using the CSS width property, the most appropriate image can be selected depending on the device that is accessing the web application.

The <picture> element consists of two tags: one or more <source> elements and an <img> element. The browser checks the first <source> element that satisfies the media query with the device that is accessing the web application, and the image specified in the srcset attribute will be displayed. The <img> element is used as the fallback option in case the media query of any <source> element is not satisfied.

In our Angular component, we define an array of configuration of the images to show in the template. In this array we define several properties:

• min/max: width viewport of the device that accesses the Web application.
• suffix: The image suffix.
• format: Format of the image, having the formats .webp and .png.

In our template, we only need to go through the array defined above to generate the <source> and <img> elements to delegate responsibility to the template.

Result

The result obtained after performing these simple steps is that we have a directory with the images in deploy with different sizes and formats to be used depending on the device that accesses the Web application. The following images show the result of our application, which downloads some images or others depending on the device that accesses the application. The images show the images that would be downloaded by a mobile device and a large screen device (large monitors or television). In this way, we are providing greater accessibility to our Web application since friendly access to a greater number of devices is being allowed.

Finally, if you want to test the entire built system we only have to use the deployment npm-script, which can be integrated in a task of our CI/CD system as it is in the original project Angular- Communities delegating the responsibility to carry out all this task to an automatic system.

Conclusion

In this post, we have been able to see how the performance and accessibility of a web application can be improved in an automated way, adapting the images according to the device that accesses the Web. In this way, users do not have to download images that are not suitable for their devices, allowing greater accessibility to the Web.

If we want to continue improving the performance of our Web applications, it is very easy to add a Service Worker that caches our static content, so that the device does not have to make requests for all the images every time it logs in. This feature is interesting if the images are not dynamic, that is, they will not undergo changes in each request of the end user.

In future posts related to this series of deployment of our frontend application, we will present how to integrate the tests automatically, allowing us to have a more complete workflow in our CI/CD system and adapted to our needs.

Introduction

In many times, an integration or deployment system is needed quickly and
effectively for our frontend applications. At other times, considerable time has been invested in the task of manually deploying our applications.

Nowadays, with the increase of commits and developers working on a software project, it is absolutely necessary to carry out this deployment automatically.

This article will introduce how to have a Build&Deploy system for
Angular applications using GitHub Actions and GitHub Pages. A prerequisite to follow this article is to have our application in the GitHub repositories.

1. Configure gh-pages

The first thing we need to do is have a branch configured where the static files will be served (html, css, js, images …). By default, GitHub has a branch called gh-pages linked to its static server that provides us with a domain in the following format https://<username>.github.io/<repository>. Therefore, the first thing we do is create the gh-page branch as shown in the following image.

We need to delete the files of our project since what will have to be in this repository are the files of our application after the build process. The steps to remove the files in the gh-pages branch are the following:

> git fetch origin gh-pages
> git checkout gh-pages
Branch 'gh-pages' set up to track remote branch 'gh-pages' from 'origin'.Switched to a new branch 'gh-pages'

Once that we are located in the appropriate branch, we only delete all the
files.

> git rm -rf .
> git add .
> git commit -m "remove files"
> git push

After these steps, your repository should be empty and then we are ready for the next step.

2. Setup an npm-script for deploy

The second step is to configure an npm script that allows us to perform the build operation instead of running this task from the terminal although Angular apps have an npm script related to the build operation. In our case, we need a more specific script in which it is specified that the build task will be done in production mode (--prod) and that the base address of our project will not be the root but the name of the repository --base-href=/<repository>/.

Therefore, we go back to the master branch and proceed to configure the
package.json file by adding the following npm script:

git checkout master

We edit the package.json file.

“deploy”: “ng build --prod --base-href=/angular-ci-cd/”

3. GitHub Actions

This is the most interesting step of this article since it is in which we are going to make use of the own tool of GitHub, GitHub Actions. To do so, go to the Actions tab in GitHub. You will see several templates to
start then.

GitHub Actions

These files are configurations in the .yml format. These files will be
automatically created in the .github/workflows directory. In our specific case we will create a file called build-deploy.yml that will have the following content:

name: Build and Deploy

on:
  push:
    branches:
      - master
jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    steps:
    - name: Checkout
      uses: actions/checkout@v1
    - uses: actions/setup-node@v1 #this installs node and npm for us
      with:
        node-version: '10.x'
    - uses: actions/cache@v1 # this allows for re-using node_modules caching, making builds a bit faster.
      with:
        path: ~/.npm
        key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          ${{ runner.os }}-node-    
    - name: Build
      run: |
        npm install
        npm run-script deploy
    - name: Deploy
      uses: JamesIves/github-pages-deploy-action@releases/v3
      with:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        BRANCH: gh-pages
        FOLDER: dist/angular-ci-cd

Let's begin to understand this file and what is being done. If you have worked previously with the .YML/.YAML file, you will already know that you must be very strict with blank or tabulated spaces since if the file is missing perfectly aligned or if you combine blank and tabulated spaces you will find problems.

• name: The name of the action to be able to identify it from other actions that we configure.
• on: When should the action be triggered? In our case,
  we only want the build and deploy process to be done when a
  push operation on the master branch is done. Observe that for that purpose we have created different levels of indentation in the build-deploy.yml file. Although it is not the goal of this post, this trigger parameter allows us to build a CI system (Continuous Integration) in which the tests of our application could be executed for any Pull Request.
• jobs: This section defines the tasks that will be carried out
  in our action. Different tasks can be defined in one
  action. In our specific case we only need to configure a single
  task that we will call build-and-deploy. In this section is where you have to define each step in the task. Therefore, we define it in greater detail below.

Jobs

The first element that is necessary to define a task is to assign a
unique identifier or name, in this specific case it is build-and-deploy. The tasks can be executed in different environments, this is described using the runs-on section that, in our case, only one environment has been defined of execution since the task is to build and deploy our
application. In the event that you want to configure test environments, this label is very interesting since it allows you to configure different environments in which will run the battery of tests on the application.

Steps

The next item in our .YML file is the sequence of steps that
performs the action that is being configured. The task we are configuring
It is made up of three steps, which are as follows:

1. Checkout.
2. Build.
3. Deploy.

1. Checkout

One of the most powerful features of GitHub Actions is that it allows
use actions created by third parties. I mean, if you always
we carry out the same steps we can parameterize and reuse them (that's a matter from another article different from this one). If we want to use a third party action we have to use the keyword uses, as shown in the
code.

- name: Checkout
  uses: actions/checkout@v1

In this task we are using the actions/checkout@v1 which is
find here: https://github.com/actions/checkout

What do we do in this task? Well, it is simple, this action performs the operation check-out from our repository on the GitHub workspace. I mean, we are performing the command git checkout in the workspace of our GitHub Actions. Thus, we have full access to the following steps of
our flow.

2. Build

The next step is to build our Angular application, exactly the same as we would do if we did it manually. So, we should install the dependencies using npm install and after should run the npm-script that we have configured for the building our application: npm run-script build. Therefore, the step called Build would be composed of these two steps, which we can describe using the run tag of GitHub Actions.

- name: Build 
  run: | 
        npm install 
        npm run-script build

3. Deploy

The last step is to perform the deploy of the application. The deploy of our application is quite simple because we only have static files (html, css and .js) once we have completed the build phase of An Angular application. Therefore, all we have to do is copy to adapt our application to GitHub Pages. This task is always the same mode, perhaps changing some settings. Therefore we will use of a third-party action that considerably facilitates the task: https://github.com/JamesIves/github-pages-deploy-action

In this action, it is important that we have to configure a TOKEN of
security to access the repository. There are different ways to display
our applications using the GitHub API:

1. SSH: using a deploy key (Deploy Key).
2. ACCESS_TOKEN: generating a secret key for a personal account
   GitHub, this must be done by creating a secret from the configuration panel from GitHub.
3. GITHUB_TOKEN: GitHub automatically creates a secret
   called GITHUB_TOKEN to use in the workflow.

We will use GITHUB_TOKEN for our deployment since it will be done from the GitHub itself to GitHub Pages therefore, we delegate the responsibility for security to the GitHub itself.

The following parameters that must be configured to deploy successfully in GitHub Pages are the branch (BRANCH) where you want deploy the code (gh-pages) and the directory (FOLDER) where the code is located.

The action to deploy (Deploy) is as shown below:

- name: Deploy 
  uses: JamesIves/github-pages-deploy-action@releases/v3                             
  with:  
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      BRANCH: gh-pages  
      FOLDER: dist/angular-ci-cd

Bonus

Using the previous steps it is enough to deploy our application. However, we may want to configure two extra steps that allow us to improve our workflow. An interesting configuration is that of require a specific version of node and/or have a cache of the node packages that have been previously installed so you don't have to install them on every build.

Therefore, the two steps that we need to configure are the following:

1. setup-node.
2. cache.

- uses: actions/setup-node@v1 
  with:  
  node-version: '10.x'  
- uses: actions/cache@v1 
  with:     
    path: ~/.npm   
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}                   
    restore-keys: |    
       ${{ runner.os }}-node-

In the example above, the node 10 version has been selected, and the
cache files have followed the instructions of the action [https://github.com/actions/cache] (https://github.com/actions/cache) where
according to the development language, it describes which files should be cached.

4. Verification

Finally, we would have to check that the Build&Deploy is being carried out, for this we move to the GitHub Actions tab where the workflow is shown.

If we navigate to the different panels we can see the log of each of
tasks:

Here, you should see that all the steps have been done satisfactorily.

Finally, we find our application in the URL: https://<user>.github.io/<repository>. In our case, We have the application deployed on this route:
https://caballerog.github.io/angular-ci-cd/

Conclusions

In this post, we have presented a quick and easy way to have configured a Build&Deploy system for Angular applications using GitHub Actions and GitHub Pages. The concepts learned in this article are transferable to any other continuous integration system.

Before using GitHub Actions and GitHub Pages, I've been deploying for months using DroneCI to a private static server and the concepts
learned from that experience have been transferred to this system of
continuous integration without any problem. Therefore, the concepts learned in this article can be easily transferred to other tools.

As of now, there is no excuse to deploy your applications in Angular from
easy and fast way. Also, it works perfectly with private repositories.