DEV Community: Carlos Caballero

Understanding Design Patterns: Observer

Carlos Caballero — Tue, 27 Apr 2021 22:19:13 +0000

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:

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.
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:

Subscriber corresponds with the class Observer.
ConcreteSubscribers correspond with the classes ConcreteObservers.
The Subject class is maintained. The attach and detach methods are renamed to subscribe and unsubscribe.
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

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.
You do not want to use busy-waiting and Polling to update observers.
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:

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.
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.

Understanding Design Patterns: Abstract Factory

Carlos Caballero — Sun, 28 Feb 2021 19:35:32 +0000

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:

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.
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

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.
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).
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:

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.
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).

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 classesConcreteProductA1 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 andAbstractProductB 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.

Understanding Design Patterns: Factory-Method

Carlos Caballero — Wed, 13 Jan 2021 10:23:02 +0000

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:

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.
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:

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.
This pattern is a specific case of the Template-Method pattern, 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.
1. 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

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.
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:

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.
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.
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:

High coupling of the ProductManager class with the system.
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.

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.

ES2021 Features with simple examples

Carlos Caballero — Sat, 02 Jan 2021 11:09:20 +0000

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:

creating weak references to objects with the WeakRef class.
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:

Or Or Equals.
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.

Understanding Design Patterns: Builder

Carlos Caballero — Thu, 17 Dec 2020 09:46:54 +0000

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

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.
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:

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.
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.
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:

BasicObject → It only consists of part A.
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.

Why You Should Learn JavaScript?

Carlos Caballero — Tue, 18 Aug 2020 16:04:11 +0000

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-tagged 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.

Automatic Adaptive Images in Angular Applications

Carlos Caballero — Mon, 08 Jun 2020 07:00:12 +0000

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.
🔥 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.

All these features make this open-source tool ideal for our purpose. First of all, we install the package as a development dependency.

rib -i <input> -o <output> <options>

The use of this tool is quite simple since we only have to specify the parameters of the following command:

"pre:deploy": "rib -i src/assets/images_raw -o src/assets/images --no-clean --force"

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.

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).

Picture Element

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.

Conclusions

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.

GitHub Repository:
https://github.com/Caballerog/angular-responsive-images

Build&Deploy Angular Apps in GitHub Pages using GitHub Actions

Carlos Caballero — Wed, 29 Apr 2020 06:08:32 +0000

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 this, go to the Actions tab in GitHub. You will see several templates to start then.

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
      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:

Checkout.
Build.
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 therun 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:

SSH: using a deploy key (Deploy Key).
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.
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 nodepackages 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:

setup-node.
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 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.

Clean Code Applied to JavaScript - Part VII: Practical Refactoring Example: Ceaser Cipher

Carlos Caballero — Tue, 07 Apr 2020 14:34:37 +0000

Introduction

Throughout this series of articles, we have presented programming techniques that allow us to generate more maintainable code. Most programming techniques and recommendations come from the "Clean Code" book and from the application of these techniques over years of experience.

In this article, I am going to describe, step by step, the application of refactoring techniques that I have applied to a code written for one of my programming fundamentals classes. If you are starting to develop software, my recommendation is that you try to solve the problem with the techniques and tools you know first (we will use JavaScript as programming language). In case you already have programming knowledge and solving the problem is not a great effort, the exercise is different. In this case, a solution is provided, the starting code, and the challenge is to apply different refactoring techniques to understand the code in depth and make this code more maintainable.

For this challenge, I have prepared a GIT repository in which you find all the versions of the algorithm that we are going to solve throughout the post step by step, using JavaScript, and a series of npm-scripts that allow you to execute the code in each one of these steps using the following nomenclature:

npm run stepX # Where X is the step

The GIT repository where you can find the code is as follows: REPOSITORY.

The Problem: Ceaser Cipher

The description of the problem is extracted from Wikipedia. So, you can read more from the original source.

Caesar Cipher, is one of the simplest and most widely known encryption techniques. It is a type of substitution cipher in which each letter in the plaintext is replaced by a letter some fixed number of positions down the alphabet. For example, with right shift of 3, E would be replaced by H, F would become I, and so on.

The transformation can be represented by aligning two alphabets; the cipher alphabet is the plain alphabet rotated right by some number of positions. For instance, here is a Caesar cipher using a right rotation of six places, equivalent to a right shift of 6:

Plain:    ABCDEFGHIJKLMNOPQRSTUVWXYZ
Cipher:   GHIJKLMNOPQRSTUVWXYZABCDEF

When encrypting, a person looks up each letter of the message in the "plain" line and writes down the corresponding letter in the "cipher" line.

Plaintext: THE QUICK BROWN FOX JUMPS OVER THE LAZY DOG
Ciphertext: QEB NRFZH YOLTK CLU GRJMP LSBO QEB IXWV ALD

Deciphering is done in reverse, with a left shift of 6.

What's and Why Refactoring?

Refactoring is a well-known topic in the software development industry. At this point, we make an introduction to the topic, but I recommend that you read the following article: https://www.cuelogic.com/blog/what-is-refactoring-and-why-is-it-important. From this article, we extract the main ideas which we are going to share here.

Refactoring is no Silver Bullet but it is a valuable weapon which benefit you to keep excellent hold on your code & so the project (software/application).

It is a scientific process of taking existing code and improves it while it makes code more readable, understandable, and clean. Also, it becomes very handy to add new features, build large applications and spot & fix bugs.

Reasons why Refactoring is Important:

To improve the design of software/application.
To make software easier to understand.
To find bugs.
To fix existing legacy database.
To provide greater consistency for user.

Original code

Once we know the problem we want to solve, we carry out an implementation that anyone who is starting out in development can reach with little time.

function cipher(text, shift) {
  var cipher = '';
  shift = shift % 26;
  for (var i = 0; i < text.length; i++) {
    if (text.charCodeAt(i) >= 65 && text.charCodeAt(i) <= 90) {
      if (text.charCodeAt(i) + shift > 90) {
        cipher = cipher.concat(
          String.fromCharCode(text.charCodeAt(i) + shift - 26),
        );
      } else {
        cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
      }
    } else if (text.charCodeAt(i) >= 97 && text.charCodeAt(i) <= 122) {
      if (text.charCodeAt(i) + shift > 122) {
        cipher = cipher.concat(
          String.fromCharCode(text.charCodeAt(i) + shift - 26),
        );
      } else {
        cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
      }
    } else {
      // blank space
      cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
    }
  }
  return cipher.toString();
}

function decipher(text, shift) {
  var decipher = '';
  shift = shift % 26;
  for (var i = 0; i < text.length; i++) {
    if (text.charCodeAt(i) >= 65 && text.charCodeAt(i) <= 90) {
      if (text.charCodeAt(i) - shift < 65) {
        decipher = decipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift + 26),
        );
      } else {
        decipher = decipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift),
        );
      }
    } else if (text.charCodeAt(i) >= 97 && text.charCodeAt(i) <= 122) {
      if (text.charCodeAt(i) - shift < 97) {
        decipher = decipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift + 26),
        );
      } else {
        decipher = decipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift),
        );
      }
    } else {
      // blank space
      decipher = decipher.concat(
        String.fromCharCode(text.charCodeAt(i) - shift),
      );
    }
  }
  return decipher.toString();
}

The code we want to develop has two methods:

cipher - Which will take the text and the shift to apply in one direction.
decipher - Performs the opposite operation of cipher. That is, decipher the text.

I recommend that, whenever you go to perform refactoring on code, you have a series of automated tests to help you verify that you have not "broken" the code. In this specific case, instead of creating a test suite, I have created two checks using the standard console.assert.

Therefore, the checks to know whether the algorithms are stable will be done through the following asserts.

console.assert(
  cipher('Hello World', 1) === 'Ifmmp!Xpsme',
  `${cipher('Hello World', 1)} === 'Ifmmp!Xpsme'`,
);
console.assert(
  decipher(cipher('Hello World', 3), 3) === 'Hello World',
  `${decipher(cipher('Hello World', 3), 3)} === 'Hello World'`,
);

Well, we already have the challenge that we are going to carry out, let's start playing!

Step 1. Magic numbers

The first step is to remove the magic numbers that appear in the code by a variable name that gives semantic value to the code. In this way, the following numbers would be modified:

The number of letters in our alphabet (26).
Each letter that belongs to the limits where the algorithm should be circular, that is:
- a: 65.
- z: 90.
- A: 97.
- Z: 122.

Therefore, we define the following constants that will allow us to have a semantic context of what each of these numbers represents.

const NUMBER_LETTERS = 26;
const LETTER = {
  a: 65,
  z: 90,
  A: 97,
  Z: 122,
};

In this way, the code will be as follows after this change.

const NUMBER_LETTERS = 26;
const LETTER = {
  a: 65,
  z: 90,
  A: 97,
  Z: 122,
};

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    if (text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z) {
      if (text.charCodeAt(i) + shift > LETTER.z) {
        cipher = cipher.concat(
          String.fromCharCode(text.charCodeAt(i) + shift - NUMBER_LETTERS),
        );
      } else {
        cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
      }
    } else if (
      text.charCodeAt(i) >= LETTER.A &&
      text.charCodeAt(i) <= LETTER.Z
    ) {
      if (text.charCodeAt(i) + shift > LETTER.Z) {
        cipher = cipher.concat(
          String.fromCharCode(text.charCodeAt(i) + shift - NUMBER_LETTERS),
        );
      } else {
        cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
      }
    } else {
      // blank space
      cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
    }
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    if (text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z) {
      if (text.charCodeAt(i) - shift < LETTER.a) {
        cipher = cipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift + NUMBER_LETTERS),
        );
      } else {
        cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) - shift));
      }
    } else if (
      text.charCodeAt(i) >= LETTER.A &&
      text.charCodeAt(i) <= LETTER.Z
    ) {
      if (text.charCodeAt(i) - shift < LETTER.A) {
        cipher = cipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift + NUMBER_LETTERS),
        );
      } else {
        cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) - shift));
      }
    } else {
      cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) - shift));
    }
  }
  return cipher.toString();
}

console.assert(
  cipher('Hello World', 1) === 'Ifmmp!Xpsme',
  `${cipher('Hello World', 1)} === 'Ifmmp!Xpsme'`,
);
console.assert(
  decipher(cipher('Hello World', 3), 3) === 'Hello World',
  `${decipher(cipher('Hello World', 3), 3)} === 'Hello World'`,
);

Step 2. Extract similar code from if-else

The next step is to identify those lines of code that are repeated in the code, so that these lines can be extracted into functions. Specifically, the assignments that exist in the bodies of the if control structures are repeated throughout the code, and these can be extracted.

That is, the following code snippet cipher = cipher.concat (String.fromCharCode ( can be extracted from the different if's that exist in the code. This line is executed after the if structure while the if that only contain the different logic according to each one of the cases.

Of course, the same operations that we perform for the cipher function are performed for the decipher function.

The code after of apply this refactoring is the following:

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;

  for (let i = 0; i < text.length; i++) {
    let character = '';
    if (text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z) {
      if (text.charCodeAt(i) + shift > LETTER.z) {
        character = text.charCodeAt(i) + shift - NUMBER_LETTERS;
      } else {
        character = text.charCodeAt(i) + shift;
      }
    } else if (
      text.charCodeAt(i) >= LETTER.A &&
      text.charCodeAt(i) <= LETTER.Z
    ) {
      if (text.charCodeAt(i) + shift > LETTER.Z) {
        character = text.charCodeAt(i) + shift - NUMBER_LETTERS;
      } else {
        character = text.charCodeAt(i) + shift;
      }
    } else {
      // blank space
      character = text.charCodeAt(i) + shift;
    }
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';

  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    let character = '';
    if (text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z) {
      if (text.charCodeAt(i) - shift < LETTER.a) {
        character = text.charCodeAt(i) - shift + NUMBER_LETTERS;
      } else {
        character = text.charCodeAt(i) - shift;
      }
    } else if (
      text.charCodeAt(i) >= LETTER.A &&
      text.charCodeAt(i) <= LETTER.Z
    ) {
      if (text.charCodeAt(i) - shift < LETTER.A) {
        character = text.charCodeAt(i) - shift + NUMBER_LETTERS;
      } else {
        character = text.charCodeAt(i) - shift;
      }
    } else {
      character = text.charCodeAt(i) + shift;
    }
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

Step 3. Avoid else

The next step is to avoid the code related to the else control structure block. Avoid it is quite easy since we simply have to move the code from the else to the variable character before the beginning of the loop so that this value is assigned as the default value.

Therefore, the code after this refactoring is as follows:

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    let character = text.charCodeAt(i) + shift;
    if (text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z) {
      if (text.charCodeAt(i) + shift > LETTER.z) {
        character = text.charCodeAt(i) + shift - NUMBER_LETTERS;
      } else {
        character = text.charCodeAt(i) + shift;
      }
    } else if (
      text.charCodeAt(i) >= LETTER.A &&
      text.charCodeAt(i) <= LETTER.Z
    ) {
      if (text.charCodeAt(i) + shift > LETTER.Z) {
        character = text.charCodeAt(i) + shift - NUMBER_LETTERS;
      } else {
        character = text.charCodeAt(i) + shift;
      }
    }
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';

  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    let character = text.charCodeAt(i) + shift;
    if (text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z) {
      if (text.charCodeAt(i) - shift < LETTER.a) {
        character = text.charCodeAt(i) - shift + NUMBER_LETTERS;
      } else {
        character = text.charCodeAt(i) - shift;
      }
    } else if (
      text.charCodeAt(i) >= LETTER.A &&
      text.charCodeAt(i) <= LETTER.Z
    ) {
      if (text.charCodeAt(i) - shift < LETTER.A) {
        character = text.charCodeAt(i) - shift + NUMBER_LETTERS;
      } else {
        character = text.charCodeAt(i) - shift;
      }
    }
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

Step 4. Merge the IF logic

The next step is tortuous for us but we have to merge the logic corresponding to the if-elseif. So that, we only have two control structures if. This action will allow us to observe in a later step that we really have two alternative paths, instead of those that appear to us.

The code after merge if logic is as follows:

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    let character = text.charCodeAt(i) + shift;
    if (
      (text.charCodeAt(i) >= LETTER.a &&
        text.charCodeAt(i) <= LETTER.z &&
        text.charCodeAt(i) + shift > LETTER.z) ||
      (text.charCodeAt(i) >= LETTER.A &&
        text.charCodeAt(i) <= LETTER.Z &&
        text.charCodeAt(i) + shift > LETTER.Z)
    ) {
      character = text.charCodeAt(i) + shift - NUMBER_LETTERS;
    }
    if (
      (text.charCodeAt(i) >= LETTER.a &&
        text.charCodeAt(i) <= LETTER.z &&
        text.charCodeAt(i) + shift > LETTER.z &&
        !(text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z)) ||
      (text.charCodeAt(i) >= LETTER.A &&
        text.charCodeAt(i) <= LETTER.Z &&
        !(text.charCodeAt(i) + shift > LETTER.Z))
    ) {
      character = text.charCodeAt(i) + shift;
    }

    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';

  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    let character = text.charCodeAt(i) - shift;
    if (
      (text.charCodeAt(i) >= LETTER.a &&
        text.charCodeAt(i) <= LETTER.z &&
        text.charCodeAt(i) - shift < LETTER.a) ||
      (text.charCodeAt(i) >= LETTER.A &&
        text.charCodeAt(i) <= LETTER.Z &&
        text.charCodeAt(i) - shift < LETTER.A)
    ) {
      character = text.charCodeAt(i) - shift + NUMBER_LETTERS;
    }
    if (
      (text.charCodeAt(i) >= LETTER.a &&
        text.charCodeAt(i) <= LETTER.z &&
        !(text.charCodeAt(i) - shift < LETTER.a)) ||
      (text.charCodeAt(i) >= LETTER.A &&
        text.charCodeAt(i) <= LETTER.Z &&
        !(text.charCodeAt(i) - shift < LETTER.A))
    ) {
      character = text.charCodeAt(i) - shift;
    }
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

Step 5. Simplifying the logic of the algorithm

In this step, we have to reason that our algorithm does not need two if control structures. Rather, both the cipher and the decipher functions have an if-else control structure. Focusing on the function cipher it is observed that there are two possible options for assigning the value to the variable character. The first possibility is the one obtained from the corresponding first if.

character = text.charCodeAt(i) + shift - NUMBER_LETTERS;

The second possible value that is obtained both in the default case and the one obtained from the other control structure if is the following ones:

character = text.charCodeAt(i) + shift;

Therefore, it is possible to remove the logic of the second if and transform the control structure into else corresponding to the first control structure if since, in the case that the condition of this if is not met, the second possible value will be assigned for the variable character. Whether the second if is fulfilled or not when assigned by the default value.

The code after of this refactoring is as follows:

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    let character;
    if (
      (text.charCodeAt(i) >= LETTER.a &&
        text.charCodeAt(i) <= LETTER.z &&
        text.charCodeAt(i) + shift > LETTER.z) ||
      (text.charCodeAt(i) >= LETTER.A &&
        text.charCodeAt(i) <= LETTER.Z &&
        text.charCodeAt(i) + shift > LETTER.Z)
    ) {
      character = text.charCodeAt(i) + shift - NUMBER_LETTERS;
    } else {
      character = text.charCodeAt(i) + shift;
    }

    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';

  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    if (
      (text.charCodeAt(i) >= LETTER.a &&
        text.charCodeAt(i) <= LETTER.z &&
        text.charCodeAt(i) - shift < LETTER.a) ||
      (text.charCodeAt(i) >= LETTER.A &&
        text.charCodeAt(i) <= LETTER.Z &&
        text.charCodeAt(i) - shift < LETTER.A)
    ) {
      character = text.charCodeAt(i) - shift + NUMBER_LETTERS;
    } else {
      character = text.charCodeAt(i) - shift;
    }
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

Step 6. Encapsulate conditionals

The condition of our algorithm is quite complex and difficult to understand because it lacks semantic value. Therefore, the next step in the code is known as encapsulate conditionals.

Specifically, we focus on encapsulating the cipher and decipher conditions:

cipher:

(text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z && text.charCodeAt(i) + shift > LETTER.z) 
||
(text.charCodeAt(i) >= LETTER.A && text.charCodeAt(i) <= LETTER.Z && text.charCodeAt(i) + shift > LETTER.Z)

decipher:

(text.charCodeAt(i) >= LETTER.a && text.charCodeAt(i) <= LETTER.z && text.charCodeAt(i) - shift < LETTER.a) 
||
(text.charCodeAt(i) >= LETTER.A && text.charCodeAt(i) <= LETTER.Z && text.charCodeAt(i) - shift < LETTER.A)

In fact, this logic can be summarized in the following four functions:

function isOutLowerCharacterCipher(text, position, shift) {
  return (
    text.charCodeAt(position) >= LETTER.a &&
    text.charCodeAt(position) <= LETTER.z &&
    text.charCodeAt(position) + shift > LETTER.z
  );
}
function isOutUpperCharacterCipher(text, position, shift) {
  return (
    text.charCodeAt(position) >= LETTER.A &&
    text.charCodeAt(position) <= LETTER.Z &&
    text.charCodeAt(position) + shift > LETTER.Z
  );
}

function isOutLowerCharacterDecipher(text, position, shift) {
  return (
    text.charCodeAt(position) >= LETTER.a &&
    text.charCodeAt(position) <= LETTER.z &&
    text.charCodeAt(position) - shift < LETTER.a
  );
}

function isOutUpperCharacterDecipher(text, position, shift) {
  return (
    text.charCodeAt(position) >= LETTER.A &&
    text.charCodeAt(position) <= LETTER.Z &&
    text.charCodeAt(position) - shift < LETTER.A
  );
}

The code after performing this encapsulation is as follows:

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    let character;
    if (
      isOutLowerCharacterCipher(text, i, shift) ||
      isOutUpperCharacterCipher(text, i, shift)
    ) {
      character = text.charCodeAt(i) + shift - NUMBER_LETTERS;
    } else {
      character = text.charCodeAt(i) + shift;
    }

    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';

  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    if (
      isOutLowerCharacterDecipher(text, i, shift) ||
      isOutUpperCharacterDecipher(text, i, shift)
    ) {
      character = text.charCodeAt(i) - shift + NUMBER_LETTERS;
    } else {
      character = text.charCodeAt(i) - shift;
    }
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

Step 7. Remove if-else structure control

The control structure if-else makes an assignment on the same variable (character). Therefore, you can extract the conditional logic from the if and store it in a variable as follows:

 const isOutAlphabet =
      isOutLowerCharacterCipher(text, i, shift) ||
      isOutUpperCharacterCipher(text, i, shift);

The assignment to the variable character is only modified by a rotation value that can have two possible values:

NUMBER_LETTERS
0 (NO_ROTATION);

Therefore, we can define the variable rotation so that it allows us to raise a level of granularity in the code as follows:

const rotation = isOutAlphabet ? NUMBER_LETTERS : NO_ROTATION;

The resulting code is as follows:

const isOutAlphabet =
isOutLowerCharacterCipher(text, i, shift) ||
isOutUpperCharacterCipher(text, i, shift);
const rotation = isOutAlphabet ? NUMBER_LETTERS : NO_ROTATION;
const character = text.charCodeAt(i) + shift - rotation;

cipher = cipher.concat(String.fromCharCode(character));

The code of the two resulting functions after this step is as follows:

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    const isOutAlphabet =
      isOutLowerCharacterCipher(text, i, shift) ||
      isOutUpperCharacterCipher(text, i, shift);
    const rotation = isOutAlphabet ? NUMBER_LETTERS : NO_ROTATION;
    const character = text.charCodeAt(i) + shift - rotation;

    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';

  shift = shift % NUMBER_LETTERS;
  for (let i = 0; i < text.length; i++) {
    const isOutAlphabet =
      isOutLowerCharacterDecipher(text, i, shift) ||
      isOutUpperCharacterDecipher(text, i, shift);
    const rotation = isOutAlphabet ? NUMBER_LETTERS : NO_ROTATION;
    const character = text.charCodeAt(i) - shift + rotation;
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

Step 8. Variable Naming

The last step to finish refactoring our algorithm is rename the variable i in loops to a more suitable name such as position (This change may seem "small" but it is very important that we assign semantic value to the variables, including the classic i, j and k in the loops.

The final result of our algorithm, after applying these simple steps are as follows:

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let position = 0; position < text.length; position++) {
    const isOutAlphabet =
      isOutLowerCharacterCipher(text, position, shift) ||
      isOutUpperCharacterCipher(text, position, shift);
    const rotation = isOutAlphabet ? NUMBER_LETTERS : NO_ROTATION;
    const character = text.charCodeAt(position) + shift - rotation;

    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';

  shift = shift % NUMBER_LETTERS;
  for (let position = 0; position < text.length; position++) {
    const isOutAlphabet =
      isOutLowerCharacterDecipher(text, position, shift) ||
      isOutUpperCharacterDecipher(text, position, shift);
    const rotation = isOutAlphabet ? NUMBER_LETTERS : NO_ROTATION;
    const character = text.charCodeAt(position) - shift + rotation;
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

Conclusions

In this post, we have presented some recommendations for do a refactoring from a basic solution to a comprehensible code.

In this post, I have shown you a step by step of my reasoning. There are other ways, of course, and some decisions may not be the most appropriate on your point of view. For all these reasons, I invite you to share your thoughts with the entire community whenever it is from a constructive point of view.

This challenge is intended to make all colleagues in the industry who think this is difficult for them. So, they can see how other colleagues perform refactoring tasks step by step.

In the next post, related to this challenge, I will continue to evolve the code by trying to give a vision of the solution from a functional programming point of view.

Finally, the points we have addressed are the following ones:

Magic numbers
Extract similar code from if-else
Avoid else
Merge the IF logic
Simplifying the logic of the algorithm
Encapsulate conditionals
Remove if-else structure control
Variable Naming

Ahh, of course, I leave you the codes, both the original and the final, so you can make a final balance of it.

function cipher(text, shift) {
  var cipher = '';
  shift = shift % 26;
  for (var i = 0; i < text.length; i++) {
    if (text.charCodeAt(i) >= 65 && text.charCodeAt(i) <= 90) {
      if (text.charCodeAt(i) + shift > 90) {
        cipher = cipher.concat(
          String.fromCharCode(text.charCodeAt(i) + shift - 26),
        );
      } else {
        cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
      }
    } else if (text.charCodeAt(i) >= 97 && text.charCodeAt(i) <= 122) {
      if (text.charCodeAt(i) + shift > 122) {
        cipher = cipher.concat(
          String.fromCharCode(text.charCodeAt(i) + shift - 26),
        );
      } else {
        cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
      }
    } else {
      // blank space
      cipher = cipher.concat(String.fromCharCode(text.charCodeAt(i) + shift));
    }
  }
  return cipher.toString();
}

function decipher(text, shift) {
  var decipher = '';
  shift = shift % 26;
  for (var i = 0; i < text.length; i++) {
    if (text.charCodeAt(i) >= 65 && text.charCodeAt(i) <= 90) {
      if (text.charCodeAt(i) - shift < 65) {
        decipher = decipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift + 26),
        );
      } else {
        decipher = decipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift),
        );
      }
    } else if (text.charCodeAt(i) >= 97 && text.charCodeAt(i) <= 122) {
      if (text.charCodeAt(i) - shift < 97) {
        decipher = decipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift + 26),
        );
      } else {
        decipher = decipher.concat(
          String.fromCharCode(text.charCodeAt(i) - shift),
        );
      }
    } else {
      // blank space
      decipher = decipher.concat(
        String.fromCharCode(text.charCodeAt(i) - shift),
      );
    }
  }
  return decipher.toString();
}

console.assert(
  cipher('Hello World', 1) === 'Ifmmp!Xpsme',
  `${cipher('Hello World', 1)} === 'Ifmmp!Xpsme'`,
);
console.assert(
  decipher(cipher('Hello World', 3), 3) === 'Hello World',
  `${decipher(cipher('Hello World', 3), 3)} === 'Hello World'`,
);

And the final code is the following ones:

const NUMBER_LETTERS = 26;
const NO_ROTATION = 0;
const LETTER = {
  a: 65,
  z: 90,
  A: 97,
  Z: 122,
};

function isOutLowerCharacterCipher(text, position, shift) {
  return (
    text.charCodeAt(position) >= LETTER.a &&
    text.charCodeAt(position) <= LETTER.z &&
    text.charCodeAt(position) + shift > LETTER.z
  );
}
function isOutUpperCharacterCipher(text, position, shift) {
  return (
    text.charCodeAt(position) >= LETTER.A &&
    text.charCodeAt(position) <= LETTER.Z &&
    text.charCodeAt(position) + shift > LETTER.Z
  );
}

function isOutLowerCharacterDecipher(text, position, shift) {
  return (
    text.charCodeAt(position) >= LETTER.a &&
    text.charCodeAt(position) <= LETTER.z &&
    text.charCodeAt(position) - shift < LETTER.a
  );
}

function isOutUpperCharacterDecipher(text, position, shift) {
  return (
    text.charCodeAt(position) >= LETTER.A &&
    text.charCodeAt(position) <= LETTER.Z &&
    text.charCodeAt(position) - shift < LETTER.A
  );
}

function cipher(text, shift) {
  let cipher = '';
  shift = shift % NUMBER_LETTERS;
  for (let position = 0; position < text.length; position++) {
    const isOutAlphabet =
      isOutLowerCharacterCipher(text, position, shift) ||
      isOutUpperCharacterCipher(text, position, shift);
    const rotation = isOutAlphabet ? NUMBER_LETTERS : NO_ROTATION;
    const character = text.charCodeAt(position) + shift - rotation;

    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

function decipher(text, shift) {
  let cipher = '';

  shift = shift % NUMBER_LETTERS;
  for (let position = 0; position < text.length; position++) {
    const isOutAlphabet =
      isOutLowerCharacterDecipher(text, position, shift) ||
      isOutUpperCharacterDecipher(text, position, shift);
    const rotation = isOutAlphabet ? NUMBER_LETTERS : NO_ROTATION;
    const character = text.charCodeAt(position) - shift + rotation;
    cipher = cipher.concat(String.fromCharCode(character));
  }
  return cipher.toString();
}

console.assert(
  cipher('Hello World', 1) === 'Ifmmp!Xpsme',
  `${cipher('Hello World', 1)} === 'Ifmmp!Xpsme'`,
);
console.assert(
  decipher(cipher('Hello World', 3), 3) === 'Hello World',
  `${decipher(cipher('Hello World', 3), 3)} === 'Hello World'`,
);

ES2016 Features with simple examples

Carlos Caballero — Thu, 30 Jan 2020 12:23:03 +0000

Introduction

ES2016 aka ES7 is the version of ECMAScript corresponding to the year 2016. This version does not 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 ES2016 in easy code examples. In this way, you can quickly understand the new features without the need for a complex explanation.

Of course, it is necessary to have a basic knowledge of JavaScript to fully understand the best ones introduced.

The new #JavaScript features in ES2016 are:

➡️ Array.prototype.includes
➡️️ Exponentiation operator

Array.prototype.includes

The includes() method determines whether an array includes a certain value among its entries, returning true or false as appropriate.

Array.prototype.includes return a Boolean which is true if the value valueToFind is found within the array.

Values of zero are all considered to be equal, regardless of sign, but false is not considered to be the same as 0.

const fruits = [🍐, 🥑, 🍇];

fruits.includes(🥑)      // true
fruits.includes(🍉)      // false
fruits.includes(🍇, 3)   // false
fruits.includes(🍇, -1)  // true
fruits.includes(NaN)  // true

If fromIndex is greater than or equal to the length of the array, false is returned. The array will not be searched.

const fruits = [🍐, 🥑, 🍇];

fruits.includes(🍇, 3)    // false
fruits.includes(🍇, 100)  // false

If fromIndex is negative, the computed index is calculated to be used as a position in the array at which to begin searching for valueToFind. If the computed index is less or equal than -1 * arr.length, the entire array will be searched.

const fruits = [🍐, 🥑, 🍇]

fruits.includes(🍐, -100) // true
fruits.includes(🥑, -100) // true
fruits.includes(🍇, -100) // true
fruits.includes(🍐, -2)   // false

// array length is 3
// fromIndex is -100
// computed index is 3 + (-100) = -97

Exponentiation operator

The exponential operator (**) is an infix operator for exponentiation.

    **Math**.pow(x,y);

produces the same result as

    x ** y

Conclusions

JavaScript is a live language, and that is something very healthy for web development. Since the appearance of ES6 in 2015 we are living a vibrant evolution in the language. In this post we have reviewed the features that arise in ES2016 (aka ES7).

Although many of these features may not be essential for the development of your Web application, they are giving possibilities that could be achieved before with tricks or a lot of verbosity.

ES2017 Features with simple examples

Carlos Caballero — Fri, 24 Jan 2020 07:53:14 +0000

Introduction

ES2017 aka ES8 is the version of ECMAScript corresponding to the year 2017. This version does not 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 ES2017 in easy code examples. In this way, you can quickly understand the new features without the need for a complex explanation.

Of course, it is necessary to have a basic knowledge of JavaScript to fully understand the best ones introduced.

The new #JavaScript features in ES2017 are:

➡️ Object.values/Object.entries
➡️️ String padding
➡️️ Object.getOwnPropertyDescriptors
➡️️ Trailing commas in function parameter lists and calls
➡️️ Async functions
➡️️ Shared memory and atomics

Object.values / Object.entries

Object values takes an object and returns an array with the values, in the same order than a for…in loop would give us.

In the other hand, Object.entries takes an object and reutrn an array with arrays of key-value pairs.

String padding

The padStart() method pads the current string with another string (multiple times, if needed) until the resulting string reaches the given length. The padding is applied from the start of the current string.

The padEnd() method pads the current string with a given string
(repeated, if needed) so that the resulting string reaches
a given length.

Object.getOwnPropertyDescriptors

getOwnPropertyDescriptors returns all own property
descriptors of a given object.

value — The value associated with the property (data descriptors only).
writable — true if and only if the value associated with the property may be changed
get — A function which serves as a getter for the property.
set — A function which serves as a setter for the property.
configurable — true if and only if the type of this property descriptor may be changed.
enumerable — true if and only if this property shows up during enumeration of the property.

Trailing commas in function parameter list and calls

There are two benefits:

You don’t have to add and remove commas if the last item changes its position.
It helps version control systems with tracking what actually changed.

Async functions

The async function declaration defines an asynchronous function — a function that return an AsyncFunction object. Asynchronous functions operate in a separate order than the rest of the code via the event loop, returning an implicit Promise as its result. But the syntax and structure of code using async functions looks like standard synchronous functions.

Shared memory and atomics

Atomics is a global variable whose methods have three main use cases.

synchronization
waiting to be notified
atomic operations

The following example illustrates you the use cases.

Conclusions

Although many of these features may not be essential for the development of your Web application, they are giving possibilities that could be achieved before with tricks or a lot of verbosity.

ES2018 Features with simple examples

Carlos Caballero — Fri, 17 Jan 2020 08:04:05 +0000

Introduction

ES2018 aka ES9 is the version of ECMAScript corresponding to the year 2018. This version does not 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 ES2018 in easy code examples. In this way, you can quickly understand the new features without the need for a complex explanation.

Of course, it is necessary to have a basic knowledge of JavaScript to fully understand the best ones introduced.

The new #JavaScript features in ES2018 are:

➡️ Lifting template literal restriction.
➡️ s (dotAll) flag for regular expressions.
➡️ RegExp named capture groups.
➡️ Rest/Spread Properties.
➡️ RegExp Lookbehind Assertions.
➡️ RegExp Unicode Property Escapes.
➡️ Promise.prototype.finally.
➡️ Asynchronous Iteration.

Lifting template literal restriction

The proposed solution is to set the cooked value to undefined for template values that contain illegal escape sequences. The raw value is still accessible via .raw so embedded DSLs that might contain undefined cooked values can just use the raw string:

s (dotAll) flag for regular expressions

Currently, the dot (.) in regular expressions doesn't match line terminator characters (previously to ES2018). The proposal specifies the regular expression flag /s.

RegExp named capture groups

Numbered capture groups allow one to refer to certain portions of a string that a regular expression matches. Each capture group is assigned a unique number and can be referenced using that number, but this can make a regular expression hard to grasp and refactor.

A capture group can be given a name using the (?...) syntax, for any identifier name. The regular expression for a date then can be written as /(?\d{4})-(?\d{2})-(?\d{2})/u. Each name should be unique.

Rest/Spread Properties

ECMAScript 6 introduces rest elements for array destructuring assignment and spread elements for array literals.

This version introduces analogous rest properties for object destructuring assignment and spread properties for object literals.

RegExp Lookbehind Assertions

There are two versions of lookbehind assertions: positive and negative.

Positive lookbehind assertions are denoted as (?<=...) and they ensure that the pattern contained within precedes the pattern following the assertion.

Negative lookbehind assertions are denoted as (?<!...) and, on the other hand, make sure that the pattern within doesn't precede the pattern following the assertion.

RegExp Unicode Property Escapes

JavaScript lets you match characters by mentioning the “names” of sets of characters. Additionally you can match characters by mentioning their Unicode character properties inside the curly braces of \p{}.

This proposal solves all the above mentioned problems:

It is no longer painful to create Unicode-aware regular expressions.
There is no dependency on run-time libraries.
The regular expressions patterns are compact and readable — no more file size bloat.
Creating a script that generates the regular expression at build time is no longer necessary.
Code that uses Unicode property escapes stays up-to-date “automatically” from the developer’s point of view: whenever the Unicode Standard gets an update, the ECMAScript engine updates its data.

Promise.prototype.finally

A finally callback execute logic once your Promise has been settled one way or the other. It has absolutely no impact on the value that your promise will resolve to.

Asynchronous Iteration

We introduce a variation of the for-of iteration statement which iterates over async iterable objects. An example usage would be:

Conclusion

Although many of these features may not be essential for the development of your Web application, they are giving possibilities that could be achieved before with tricks or a lot of verbosity.