DEV Community: michael matos

Applicatives in typescript

michael matos — Wed, 15 May 2024 03:15:05 +0000

Functors recap
Applicatives:
Multiple arguments
Sequential or parallel effectful computation composition
Practical examples:

In functional programming (FP), applicatives are a step beyond functors in terms of power and flexibility. Let's start by reviewing functors:

Functors recap

Functors are a common concept in FP that represent types that can be mapped over. They typically have a map function that takes a function and applies it to the values inside, preserving the structure.
Functors allow us to work with values within a context (like a list, Maybe, etc.) without altering that context.

here's the interface:

interface Functor<T> {
    map<U>(fn: (value: T) => U): Functor<U>;
}

Applicatives

Applicatives are an extension of functors. While functors allow us to apply a function to values inside a context, applicatives allow us to apply a function that is itself inside a context to values that are also inside a context.
Applicatives introduce two main functions: pure or of(in typescript) and <*> or ap(for apply).
- pure takes a value and wraps it in a default context.
- ap takes a function wrapped in a context and applies it to a value also wrapped in a context, producing a result wrapped in the same context.
Applicatives are more powerful than functors because they allow us to work with functions themselves as values within a context, enabling more complex operations.
While functors preserve the structure of the context, applicatives allow for more intricate manipulation, including combining multiple contexts or functions within contexts.

interface Functor<T> {
    map<U>(fn: (value: T) => U): Functor<U>;
}

interface Applicative<T> extends Functor<T> {
    of<U>(value: U): Applicative<U>;
    ap<U>(fnContainer: Applicative<(value: T) => U>): Applicative<U>;
}

1. `T` represents the type of values contained within the functor.
2. `map` is the same as in the Functor interface, mapping a function over the functor's values.
3. `of` (also known as `pure` in Haskell) lifts a value into the functorial context.
4. `ap` (also known as `<*>` in Haskell) applies a function within the functor context to a value also within the functor context.

Multiple arguments

A small detour: curried functions:
A curried function is a function that takes multiple arguments one at a time, returning a new function after each argument is provided. This allows for partial application of the function, meaning you can call the function with fewer arguments than its arity (the number of arguments it expects), and it will return a new function that takes the remaining arguments.

// Non-curried function to calculate the area of a rectangle
function calculateRectangleArea(width: number, height: number): number {
    return width * height;
}

// Curried version of the calculateRectangleArea function using arrow function syntax
const curriedCalculateRectangleArea = (width: number) => (height: number): number => {
    return width * height;
};

// Usage of the non-curried function
const area1 = calculateRectangleArea(10, 5); // Width: 10, Height: 5
// Result: 50

// Usage of the curried function for partial application
const calculateAreaWithWidth10 = curriedCalculateRectangleArea(10); // Fix the width at 10
const area2 = calculateAreaWithWidth10(5); // Provide the height: 5
// Result: 50

One of the key advantages of applicatives over functors is their ability to work with functions that take multiple arguments. With functors, we can only map single-argument functions over values within a context. But with applicatives, we can apply multi-argument functions to values within contexts.

Sequential or parallel effectful computation composition

Applicatives are particularly useful when dealing with effectful computations, where the result of one computation depends on the result of another.
Sequential composition is achieved by chaining computations using ap, ensuring that each computation is performed in order, with the results combined into a single context.
Parallel composition involves applying multiple computations concurrently and combining their results into a single context. This can lead to performance improvements when computations can be executed independently.

// Define an Applicative interface
interface Applicative<T> {
  ap<U>(fnContainer: Applicative<(value: T) => U>): Applicative<U>;
  of<U>(value: U): Applicative<U>;
}

// Implement the Applicative interface for Promises
class PromiseApplicative<T> implements Applicative<T> {
  constructor(private promise: Promise<T>) {}

  ap<U>(
    fnContainer: PromiseApplicative<(value: T) => U>
  ): PromiseApplicative<U> {
    return new PromiseApplicative(
      Promise.all([this.promise, fnContainer.promise]).then(([value, fn]) =>
        fn(value)
      )
    );
  }

  of<U>(value: U): PromiseApplicative<U> {
    return new PromiseApplicative(Promise.resolve(value));
  }
}

// Simulating asynchronous operations to fetch user data
function fetchUserName(): Promise<string> {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve("John"); // Simulated user name
    }, 1000); // Simulated delay of 1 second
  });
}

function fetchUserAge(): Promise<number> {
  return new Promise((resolve) => {
    setTimeout(() => {
      resolve(30); // Simulated user age
    }, 1500); // Simulated delay of 1.5 seconds
  });
}

// Define a curried function to calculate the year the user was born
const calculateBirthYear = (age: number) => new Date().getFullYear() - age;

// Define a curried function to concatenate the user's name and birth year
const concatenateUserInfo = (name: string) => (birthYear: number) =>
  `${name}, born in ${birthYear}`;

// Create Applicative instances for fetching user data
const nameApplicative = new PromiseApplicative(fetchUserName());
const ageApplicative = new PromiseApplicative(fetchUserAge());

// Apply the calculateBirthYear function to the ageApplicative
const birthYearApplicative = ageApplicative.ap(
  new PromiseApplicative(Promise.resolve(calculateBirthYear))
);

// Apply the concatenateUserInfo function to the nameApplicative and birthYearApplicative
const userInfoApplicative = birthYearApplicative.ap(
  nameApplicative.ap(
    new PromiseApplicative(Promise.resolve(concatenateUserInfo))
  )
);

// Get the result
userInfoApplicative.promise.then((userInfo) => {
  console.log(userInfo); // Output: John, born in 1992
});

Practical examples

Applicatives find practical applications in various domains, such as parsing, validation, concurrent programming, and user interface programming.
For instance, in parsing, combinators can be built using applicative operations to sequence and combine parsers.
In validation, applicatives can be used to combine and validate multiple inputs independently and accumulate errors.

Mappables in typescript

michael matos — Sun, 12 May 2024 21:31:03 +0000

*note: I could never explain these things better than: this guy so I suggest you to go there and read this as complementary material and *

Functors == mappable
are there other functors, Maybe
Trees can be mappables
So graphs too
Benefits of using functors in your code

Functors == mappable

Once upon a time in the kingdom of Functional Paradise, there lived a clever magician named Funcio. Funcio had a magical box called "The Functor" that could transform ordinary objects into extraordinary ones.

One sunny day, a young princess named Polya approached Funcio with a basket of fruits. She wanted to make these fruits more delightful, so Funcio decided to demonstrate the power of his Functor. He waved his wand and exclaimed, "Behold the magic of mapping!"

With a flick of his wrist, Funcio turned the basket of fruits into a basket of fruity delights. Each fruit was transformed into its juiciest and ripest version, making them even more delicious than before.

Princess Polya was amazed and asked Funcio, "How did you do that?"

Funcio chuckled and explained, "You see, dear princess, the Functor is like a magical function that takes ordinary things and makes them extraordinary. Just like how we transformed your fruits, functors in functional programming take values and apply a function to each of them, creating new values without changing the original ones."

// and here's the interface ("typeclass") for mappable things
interface Functor<F> { map<T, U>(fa: F, func: (x: T) => U): F; }

// and here's the example impl.
type List<T> = null | { head: T; tail: List<T> };

function cons<T>(head: T, tail: List<T>): List<T> {
    return { head, tail };
}

function map<T, U>(list: List<T>, func: (x: T) => U): List<U> {
    if (list === null) {
        return null;
    } else {
        return cons(func(list.head), map(list.tail, func));
    }
}

// Example usage:
function transformToFruityDelight(fruit: string): string {
    return "Delightful " + fruit;
}

// Create a list of fruits
const fruits: List<string> = cons("apple", cons("banana", cons("orange", null)));

// Apply the transformation function to each fruit
const fruityDelights: List<string> = map(fruits, transformToFruityDelight);

// Print the original and transformed lists
console.log("Original list:", fruits);
console.log("Transformed list:", fruityDelights);

From that day on, Princess Polya became fascinated with functors and their magical powers. She embarked on a journey to learn more about functional programming, guided by the wisdom of Funcio the magician.

And so, in the kingdom of Functional Paradise, the tale of Funcio and his Functor spread far and wide, inspiring many to explore the enchanting world of functional programming.

Are there other functors, Maybe

Funcio, being a wise magician, knew that there were many more magical Functors beyond just lists. So, he gathered Princess Polya and his other curious apprentices for a special lesson.

Gathering them around his magical Functor box, Funcio began, "Dear friends, behold the wonders of Functors are not confined to just lists. They can take many forms, each with its own unique magic."

He then waved his wand and summoned an array of objects: trees, potions, and even a flock of birds.

"These," Funcio proclaimed, "are all Functors in disguise!"

Princess Polya and the apprentices gasped in awe.

Funcio continued, "Just as we transformed lists of fruits into a basket of delights, we can apply the Functor's magic to arrays, streams, Maybe types, and many more! Each Functor has its own way of applying transformations, but the essence remains the same: taking ordinary values and bestowing upon them the magic of functional programming."

With wide eyes, Princess Polya asked, "But how do we know which types can be Functors?"

Funcio smiled warmly, "Ah, dear princess, any type that can map a function over its values while preserving its structure can be a Functor. It's not about what it is, but how it behaves!"

And so, Funcio and his apprentices delved deeper into the world of Functors, exploring the diverse forms they could take and the magical transformations they could bring. With each lesson, they discovered new wonders and expanded their understanding of functional programming in the kingdom of Functional Paradise.

// Define Just and Nothing data types
type Just<T> = { kind: "just"; value: T };
type Nothing = { kind: "nothing" };

// Define Maybe Functor ADT
type Maybe<T> = Just<T> | Nothing;

// Define a function to wrap a value in Just
function just<T>(value: T): Just<T> {
  return { kind: "just", value };
}

// Define a constant for Nothing
const nothing: Nothing = { kind: "nothing" };

// Define a function to apply a transformation over Maybe Functor
function mapMaybe<T, U>(maybe: Maybe<T>, fn: (val: T) => U): Maybe<U> {
  switch (maybe.kind) {
    case "just":
      return just(fn(maybe.value));
    case "nothing":
      return nothing;
  }
}

// Define a Tree ADT
type Tree = { hasFruit: boolean };

// Define a function to bear fruit
function bearFruit(tree: Tree): string {
  return tree.hasFruit ? "🍎" : "No Fruit";
}

// Create some trees
const tree1: Tree = { hasFruit: true };
const tree2: Tree = { hasFruit: false };
const tree3: Tree = { hasFruit: true };

// Wrap trees in Maybe Functor
const maybeTree1: Maybe<Tree> = tree1.hasFruit ? just(tree1) : nothing;
const maybeTree2: Maybe<Tree> = tree2.hasFruit ? just(tree2) : nothing;
const maybeTree3: Maybe<Tree> = tree3.hasFruit ? just(tree3) : nothing;

// Map the bearFruit function over Maybe Functor
const result1: Maybe<string> = mapMaybe(maybeTree1, bearFruit); // Returns Just("🍎")
const result2: Maybe<string> = mapMaybe(maybeTree2, bearFruit); // Returns Nothing
const result3: Maybe<string> = mapMaybe(maybeTree3, bearFruit); // Returns Just("🍎")

// Log results
console.log(result1);
console.log(result2);
console.log(result3);

Trees can be mappables

// Define a binary tree data type
type Tree<T> = null | { value: T; left: Tree<T>; right: Tree<T> };

// Function to create a new tree node
function treeNode<T>(value: T, left: Tree<T> = null, right: Tree<T> = null): Tree<T> {
    return { value, left, right };
}

// Functor interface for trees
interface Functor<F> {
    map<T, U>(fa: F, func: (x: T) => U): F;
}

// Tree Functor implementation
class TreeFunctor implements Functor<Tree<any>> {
    map<T, U>(tree: Tree<T>, func: (x: T) => U): Tree<U> {
        if (tree === null) {
            return null;
        } else {
            return treeNode(func(tree.value), this.map(tree.left, func), this.map(tree.right, func));
        }
    }
}

// Example usage:
function square(x: number): number {
    return x * x;
}

// Create a sample binary tree
const binaryTree: Tree<number> = treeNode(
    1,
    treeNode(2, treeNode(3), treeNode(4)),
    treeNode(5, null, treeNode(6))
);

// Create a TreeFunctor instance
const treeFunctor = new TreeFunctor();

// Map over the binary tree to square each node value
const squaredTree: Tree<number> = treeFunctor.map(binaryTree, square);

// Print the original and transformed trees
console.log("Original tree:", binaryTree);
console.log("Squared tree:", squaredTree);

So graphs too

type Edge<T> = {
    target: Vertex<T>;
    weight?: number; // Optional weight for the edge
};

class Vertex<T> {
    value: T;
    edges: Array<Edge<T>>;

    constructor(value: T) {
        this.value = value;
        this.edges = [];
    }

    addEdge(target: Vertex<T>, weight?: number): void {
        this.edges.push({ target, weight });
    }
}

class Graph<T> {
    vertices: Array<Vertex<T>>;

    constructor(vertices: Array<Vertex<T>>) {
        this.vertices = vertices;
    }
}

interface Functor<F> {
    map<T, U>(graph: F, func: (x: T) => U): F;
}

class GraphFunctor implements Functor<Graph<any>> {
    map<T, U>(graph: Graph<T>, func: (x: T) => U): Graph<U> {
        const newVertices: Array<Vertex<U>> = graph.vertices.map(vertex => {
            return {
                value: func(vertex.value),
                edges: vertex.edges.map(edge => {
                    return {
                        target: this.mapVertex(edge.target, func),
                        weight: edge.weight
                    };
                })
            };
        });

        return new Graph(newVertices);
    }

    private mapVertex<T, U>(vertex: Vertex<T>, func: (x: T) => U): Vertex<U> {
        return {
            value: func(vertex.value),
            edges: vertex.edges.map(edge => {
                return {
                    target: this.mapVertex(edge.target, func),
                    weight: edge.weight
                };
            })
        };
    }
}


// Define the graph data structure, Functor interface, and GraphFunctor implementation as provided previously...

// Create vertices
const v1 = new Vertex("A");
const v2 = new Vertex("B");
const v3 = new Vertex("C");

// Add edges between vertices
v1.addEdge(v2);
v1.addEdge(v3);
v2.addEdge(v3);

// Create the graph
const graph = new Graph([v1, v2, v3]);

// Create a function to transform vertex values (e.g., converting to uppercase)
function transformToUpper(value: string): string {
    return value.toUpperCase();
}

// Create an instance of the GraphFunctor
const graphFunctor = new GraphFunctor();

// Map over the graph, transforming vertex values to uppercase
const transformedGraph = graphFunctor.map(graph, transformToUpper);

// Output the original and transformed graphs
console.log("Original Graph:");
console.log(graph);
console.log("\nTransformed Graph:");
console.log(transformedGraph);

Benefits of using functors in your code

Functional programming leverages functors for various reasons, each contributing to the paradigm's elegance, composability, and safety. Here are some benefits of using functors in FP:

Abstraction: Functors provide a powerful abstraction mechanism that enables developers to encapsulate common patterns of computation. They allow us to define generic operations over different data types, promoting code reuse and modularity.
Composition: Functors support composition, allowing developers to build complex transformations by combining simpler ones. By chaining multiple functor operations together, we can express intricate computations concisely and clearly.
Laws and Guarantees: Functors come with laws that ensure their behavior is predictable and consistent. For example, the functor laws dictate that mapping the identity function over a functor should return the original functor, and composing two functor mappings should be equivalent to mapping the composition of the functions. These laws provide guarantees about functor behavior, helping developers reason about their code's correctness.
Separation of Concerns: Functors encourage separating concerns by distinguishing between data transformation and the application of specific functions. This separation enhances code clarity and maintainability by decoupling the logic of the transformation from the specifics of the operations applied.
Error Handling: Functors facilitate error handling by providing a structured way to handle failures or exceptions within computations. They allow developers to define functor-specific error-handling strategies, such as lifting errors into a functor context or mapping over functors to propagate errors.
Parallelism and Concurrency: Functors support parallelism and concurrency by enabling the application of pure functions to data in a distributed manner. By abstracting over data transformation, functors make it easier to parallelize computations without worrying about synchronization or side effects.
Type Safety: Functors promote type safety by constraining the types of data that can be transformed and the functions that can be applied. This ensures that operations are applied in a consistent and predictable manner, reducing the likelihood of runtime errors and bugs.
Interoperability: Functors facilitate interoperability between different libraries and frameworks by providing a common interface for data transformation. This enables developers to seamlessly integrate code written in different paradigms or languages, fostering collaboration and code reuse.

thank you...
FIN!!!

Algebraic structures in FP

michael matos — Wed, 08 May 2024 02:01:01 +0000

what do we mean by algebraic structure
Laws
Reasoning for laws
Relationship between structures
Groups are everywhere

what do we mean by algebraic structure

An algebraic structure is a mathematical "object"(system, setup, tuple) consisting of a set of elements equipped with one or more operations that satisfy certain properties, axioms or laws. These structures provide a formal framework for studying and understanding the relationships and properties of mathematical objects.

In general, an algebraic structure is defined by:

Underlying Set: A non-empty set 𝑆 whose elements are the building blocks of the structure.
Operations: One or more operations defined on the set 𝑆S. These operations can include addition, multiplication, composition, etc., depending on the specific structure.
Properties, Axioms or laws: A set of properties or axioms that the operations must satisfy to define the structure. These properties may include closure, associativity, commutativity, identity elements, and inverses, among others. (please don't jump at the high school memories)

here's a short list of algebraic structures from which we'll pick the ones that are actually used in functional programming.

Magma
Semigroup
Monoid
Group
Abelian group
Ring
Field

Sounds abstract and a bit foreign? of course it does but see algebraic structures all the time in computer programming and your real life.

Laws

We're going to take the a group-like structure to demonstrate the laws (that you should already know) as is the structure that encompass the most laws of the list

// Define a type for the elements of the group
type GroupElement = number;

// Define the group interface
interface Group {
  // Binary operation
  operation(x: GroupElement, y: GroupElement): GroupElement;

  // Identity element
  identity: GroupElement;

  // Inverse operation
  inverse(x: GroupElement): GroupElement;
}

// Define a function to check if an object satisfies the Group interface
function isGroup(object: any): object is Group {
  return (
    typeof object.operation === 'function' &&
    typeof object.identity !== 'undefined' &&
    typeof object.inverse === 'function'
  );
}

// Define a concrete implementation of a group: integers under addition
const integerAdditionGroup: Group = {
  operation: (x, y) => x + y,
  identity: 0,
  inverse: x => -x,
};

// Test the properties of the group
function testGroupProperties(group: Group): boolean {
  const { operation, identity, inverse } = group;
  // Closure property
  const closure = (a: GroupElement, b: GroupElement) => isGroup(operation(a, b));
  // Associativity property
  const associativity = (a: GroupElement, b: GroupElement, c: GroupElement) =>
    operation(a, operation(b, c)) === operation(operation(a, b), c);
  // Identity property
  const identityElement = (a: GroupElement) => operation(a, identity) === a && operation(identity, a) === a;
  // Inverse property
  const inverseElement = (a: GroupElement) => operation(a, inverse(a)) === identity && operation(inverse(a), a) === identity;
  // Test properties for a range of elements
  for (let i = -100; i <= 100; i++) {
    if (!closure(i, i) || !associativity(i, i, i) || !identityElement(i) || !inverseElement(i)) {
      return false;
    }
  }
  return true;
}

// Test if integers under addition form a group
console.log(testGroupProperties(integerAdditionGroup)); // Output: true

Reasoning for laws

But first a detour through similes between math laws and society's legal laws to make the point more clear.

Air travel industry:
Failure to adhere to safety regulations and standards can result in accidents and incidents with devastating consequences. for example, if an airline neglects maintenance procedures or ignores safety protocols, it increases the risk of mechanical failures, mid-air emergencies, and crashes.

Food industry:
Failure to comply with food safety regulations can lead to contamination of food products with pathogens, toxins, or foreign objects. Contaminated food can cause foodborne illnesses, outbreaks of diseases such as salmonella or E. coli, and potentially fatal consequences for consumers.

laws provide predictability, confidence, order, stability likewise in the world of software development they give us the same:

Correctness and Reliability: Laws define expected behavior and properties of functional constructs. By adhering to these laws, developers can write code that behaves predictably and reliably. For example, the associativity law for monoids ensures that combining values in different orders yields the same result, which helps maintain correctness in programs that use monoidal operations.
Equational Reasoning: Laws enable equational reasoning, which allows developers to reason about code by substituting expressions that are known to be equivalent. This simplifies reasoning and facilitates understanding, debugging, and refactoring of functional code. For instance, knowing the laws of monads allows developers to reason about sequences of computations in a clear and systematic way.
Abstraction and Composition: Laws provide a foundation for abstraction and composition in functional programming. By defining common properties and behaviors, laws enable the creation of composable and reusable components. Developers can leverage these abstractions confidently, knowing that they adhere to well-defined laws and can be combined safely.
Verification and Testing: Laws serve as a basis for verifying the correctness of functional code through testing. Developers can write property-based tests that validate whether code adheres to specified laws. If code violates these laws, it indicates potential bugs or incorrect implementations, enabling early detection and resolution of issues.
Interoperability and Interchangeability: Laws promote interoperability and interchangeability of functional components. Functional constructs that satisfy the same laws can be used interchangeably, regardless of their specific implementations. This enables developers to mix and match components from different libraries or languages seamlessly, fostering code reuse and modularity.

Relationship between structures

Construction from Smaller Structures: Some algebraic structures can be constructed from simpler ones. For instance, a group is just a monoid that adds an inverse element for each element in the original set and likewise a monoid is just a semigroup that adds one element which combined with any other elements returns the latter. We've already saw that the set of integers under addition forms a Group if we take the negative numbers and start from the 0 onwards we have a monoid, but if we then take the 0 which is the identity element we end only with positive integers that together with the combine function forms a semigroup.

Containment Hierarchies: Certain algebraic structures contain or are substructures of others.
This is very interesting given that the majority of the primitives in your programming language of choice falls implicitly under one of these structures and we can make them conform to the structures interfaces very easily and get all the benefits of the laws automatically and for free. let's see an example, JSON:

We can convert a JSON document very easily into a monoid (which is one of the most useful and used structures) by converting all of its fields into monoids and delegating the sub-operations. Isn't this just cool?

(A quick-n-dirty naive version would be like this)

type JsonValue = string | number | boolean | null | JsonObject | JsonArray;
type JsonObject = { [key: string]: JsonValue };
type JsonArray = JsonValue[];

// Define a monoid interface for JSON values
interface JsonMonoid {
  empty: JsonValue;
  concat: (x: JsonValue, y: JsonValue) => JsonValue;
}

// Define monoids for each JSON data type
const stringMonoid: JsonMonoid = {
  empty: "",
  concat: (x, y) => `${x}${y}`,
};

const numberMonoid: JsonMonoid = {
  empty: 0,
  concat: (x, y) => x + y,
};

const booleanMonoid: JsonMonoid = {
  empty: false,
  concat: (x, y) => x || y,
};

const nullMonoid: JsonMonoid = {
  empty: null,
  concat: (_, y) => y,
};

const objectMonoid: JsonMonoid = {
  empty: {},
  concat: (x, y) => {
    const result: JsonObject = { ...x };

    for (const key in y) {
      if (y.hasOwnProperty(key)) {
        result[key] = key in result ? objectMonoid.concat(result[key], y[key]) : y[key];
      }
    }

    return result;
  },
};

const arrayMonoid: JsonMonoid = {
  empty: [],
  concat: (x, y) => [...x, ...y],
};

// Define a function to recursively apply the monoid operation based on the JSON value type
const mergeJsonValues = (x: JsonValue, y: JsonValue): JsonValue => {
  if (typeof x !== typeof y) {
    throw new Error("Incompatible types");
  }

  if (typeof x === "object" && x !== null && Array.isArray(x) === Array.isArray(y)) {
    // Recursively merge arrays and objects
    return Array.isArray(x) ? arrayMonoid.concat(x, y as JsonArray) : objectMonoid.concat(x as JsonObject, y as JsonObject);
  } else {
    // Delegate to the appropriate monoid based on the data type
    switch (typeof x) {
      case "string":
        return stringMonoid.concat(x as string, y as string);
      case "number":
        return numberMonoid.concat(x as number, y as number);
      case "boolean":
        return booleanMonoid.concat(x as boolean, y as boolean);
      case "object":
        return nullMonoid.concat(x as null, y as null);
    }
  }
};

// Test the monoid
const obj1: JsonObject = { a: { b: 1 }, c: 2 };
const obj2: JsonObject = { a: { d: 3 }, e: 4 };

const result = objectMonoid.concat(obj1, obj2);
console.log(result); // Output: { a: { b: 1, d: 3 }, c: 2, e: 4 }

From the last example you now see that objets and arrays form a monoid too, you just didn't know they were

Groups are everywhere

from the clock on the wall:

class ClockGroup {
    private readonly size: number;
    private readonly hours: number[];

    constructor(size: number) {
        this.size = size;
        this.hours = Array.from({ length: size }, (_, i) => i);
    }

    add(clock1: number, clock2: number): number {
        return (clock1 + clock2) % this.size;
    }

    subtract(clock1: number, clock2: number): number {
        return (clock1 - clock2 + this.size) % this.size;
    }

    identity(): number {
        return 0;
    }

    inverse(clock: number): number {
        return (this.size - clock) % this.size;
    }

    print(): void {
        console.log("Clock Group:");
        console.log("Elements:", this.hours);
        console.log("Size:", this.size);
    }
}

// Example usage
const clockGroup = new ClockGroup(12);
clockGroup.print();

console.log("Addition (5 + 7):", clockGroup.add(5, 7)); // Output: 0 (12-hour clock wraps around)
console.log("Subtraction (7 - 5):", clockGroup.subtract(7, 5)); // Output: 2
console.log("Identity element:", clockGroup.identity()); // Output: 0
console.log("Inverse of 8:", clockGroup.inverse(8)); // Output: 4

to rubik's cube:

// Define a type for the colors of the Rubik's Cube faces
type CubeColor = 'red' | 'blue' | 'green' | 'orange' | 'white' | 'yellow';

// Define a type for the Rubik's Cube face
interface CubeFace {
    color: CubeColor;
}

// Define a type for the Rubik's Cube
type RubiksCube = CubeFace[][][];

// Define a Group interface
interface Group<T> {
    operation(a: T, b: T): T;
    identity: T;
    inverse(a: T): T;
}

// Define the Rubik's Cube group interface that extends the Group interface
interface RubiksCubeGroup extends Group<CubeRotationCommand> {
    // No additional methods needed as rotation commands directly represent cube rotations
}

// Define a rotation command interface
interface CubeRotationCommand {
    axis: 'x' | 'y' | 'z'; // Axis of rotation
    layer: number; // Layer of the cube to rotate
    direction: 'clockwise' | 'counter-clockwise'; // Direction of rotation
}

// Implementation of RubiksCubeGroup
class MyRubiksCubeGroup implements RubiksCubeGroup {
    operation(command1: CubeRotationCommand, command2: CubeRotationCommand): CubeRotationCommand {
        // Combine two rotation commands
        // In practice, this could involve composing the sequences of rotations
        return command1; // Placeholder implementation
    }

    get identity(): CubeRotationCommand {
        // Identity element: no rotation
        return { axis: 'x', layer: 0, direction: 'clockwise' }; // Placeholder implementation
    }

    inverse(command: CubeRotationCommand): CubeRotationCommand {
        // Inverse of a rotation command
        // In practice, this could involve reversing the rotation
        return command; // Placeholder implementation
    }
}

// Example usage
const rubiksCubeGroup: RubiksCubeGroup = new MyRubiksCubeGroup();
console.log("Identity:", rubiksCubeGroup.identity);
console.log("Inverse of 'U':", rubiksCubeGroup.inverse('U'));
console.log("Operation of 'U' and 'R':", rubiksCubeGroup.operation('U', 'R'));

overall everywhere you find some kind of symmetry there's good chance you'll find a type of algebraic structure.

FIN

typelevel typescript: a practical view

michael matos — Sat, 04 May 2024 17:24:05 +0000

Benefits of typelevel computation:
Some use cases
Validation, verification and contracts
DSLs and embedded languages:
Configuration and Settings
All that glitters is not gold: typelevel drawbacks
Who is the perfect audience for typelevel computation

Benefits of typelevel computation:

Type-level computation in TypeScript, or any statically typed language, offers several benefits that can improve code safety, maintainability, and developer productivity:

Compile-time safety: Type-level computation enables catching errors at compile time rather than runtime. This results in early detection of issues, reducing the likelihood of bugs and runtime errors in production code.
Improved code correctness: By using type-level computation, developers can define and enforce constraints, contracts, and invariants directly in the type system. This ensures that code adheres to specified rules, leading to more robust and correct software.
Enhanced developer experience: Type-level computation provides better tooling support, including autocomplete, type inference, and type checking. This helps developers write code more efficiently and with fewer errors, leading to a smoother development experience.
Refactoring confidence: Type-level computation helps maintain code consistency during refactoring. Since types accurately reflect the structure and constraints of data, refactoring tools can provide better guidance and ensure that changes don't violate existing contracts.
Documentation and self-documenting code: Type-level computation serves as a form of documentation by describing the shape and behavior of data directly in the code. Well-defined types act as self-documenting entities, making it easier for developers to understand code and collaborate effectively.
Code maintainability(double edged sword, see drawbacks section): Type-level computation promotes code maintainability by providing a clear and explicit representation of data structures, constraints, and transformations. This makes it easier to reason about code, identify potential issues, and make changes with confidence.
Reduced runtime overhead: Since type-level computations occur at compile time, there's no runtime overhead associated with type checking or validation. This can lead to improved performance, especially in performance-critical applications.

Overall, type-level computation offers significant benefits in terms of code safety, correctness, maintainability, and developer productivity, making it a valuable tool for building reliable and maintainable software systems.

Some use cases

Type-level programming in TypeScript offers several powerful capabilities that can be leveraged to solve a variety of problems at compile time. Here are some common use cases for type-level programming in TypeScript:

Validation, verification and contracts

Enforcing data validation rules at compile time, such as validating input parameters, ensuring correct usage of APIs, and preventing invalid states.

for example URL validation:

// Define a type for valid URL schemes
type ValidScheme = 'http' | 'https' | 'ftp' | 'ssh';

// Define a type for valid domains
type ValidDomain = 'example.com' | 'example.org' | 'example.net';

// Define a type-level function to validate URL scheme
type ValidateScheme<T extends string> = T extends `${ValidScheme}://${string}` ? T : never;

// Define a type-level function to validate domain
type ValidateDomain<T extends string> = T extends `${ValidScheme}://${ValidDomain}/${string}` ? T : never;

// Define a type-level function to validate query parameters
type ValidateQueryParams<T extends string> = T extends `${string}?${string}` ? T : never;

// Combine all validation functions into a single function
type ValidateURL<T extends string> = ValidateQueryParams<ValidateDomain<ValidateScheme<T>>>;

// Example usage:
type ValidURL = ValidateURL<'http://example.com/path?param=value'>;
type InvalidURL = ValidateURL<'http://invalid-url.com/path?param=value'>;

// This will work because ValidURL matches the URL pattern
const validURL: ValidURL = 'http://example.com/path?param=value';

// This will result in a compilation error because InvalidURL does not match the URL pattern
const invalidURL: InvalidURL = 'http://invalid-url.com/path?param=value'; // Error: Type '"http://invalid-url.com/path?param=value"' does not match the expected type 'never'

or any other contract in general:

// Define the contract for a user object
type UserContract = {
  id: string;
  name: string;
  age: number;
  address?: {
    street: string;
    city: string;
    postalCode: string;
  };
};

// Define a type-level function to enforce the contract
type EnforceContract<T> = T extends UserContract ? EnforceUser<T> : never;

// Define a helper type to enforce the contract for a user object
type EnforceUser<T> = {
  [K in keyof T]: K extends 'address' ? EnforceAddress<T[K]> : T[K];
};

// Define a helper type to enforce the contract for the address object
type EnforceAddress<T> = {
  [K in keyof T]: T[K];
};

// Example usage:
type ValidUser = EnforceContract<{
  id: string;
  name: string;
  age: number;
  address: {
    street: string;
    city: string;
    postalCode: string;
  };
}>;

type PartialUser = EnforceContract<{
  id: string;
  name: string;
  age: number;
  address?: {
    street: string;
    city: string;
    postalCode: string;
  };
}>;

type InvalidUser = EnforceContract<{
  id: string;
  name: string;
  age: string; // Invalid type
  address: {
    street: string;
    city: string;
    postalCode: string;
    country: string; // Invalid property
  };
}>;

// This will work because ValidUser matches the UserContract
const validUser: ValidUser = {
  id: '1',
  name: 'John',
  age: 30,
  address: {
    street: '123 Main St',
    city: 'Anytown',
    postalCode: '12345',
  },
};

// This will work because PartialUser matches the UserContract
const partialUser: PartialUser = {
  id: '2',
  name: 'Jane',
  age: 25,
};

// This will result in a compilation error because InvalidUser does not match the UserContract
const invalidUser: InvalidUser = {
  id: '3',
  name: 'Doe',
  age: '25', // Error: Type 'string' is not assignable to type 'number'
  address: {
    street: '456 Elm St',
    city: 'Othertown',
    postalCode: '54321',
    country: 'USA', // Error: Object literal may only specify known properties, and 'country' does not exist in type 'EnforceAddress<{ street: string; city: string; postalCode: string; }>'
  },
};

DSLs and embedded languages:

Type-level computation can significantly benefit the creation of Domain-Specific Languages (DSLs) by enforcing constraints, ensuring correctness, and providing a high level of abstraction. Let's consider an example of creating a DSL for building SQL queries using type-level computation in TypeScript.

We'll define a DSL that allows users to construct SQL queries fluently with type safety, ensuring that only valid SQL constructs are used. We'll use mapped types, conditional types, and generics to achieve this.

// Define a type representing SQL operators
type SQLOperator = '=' | '<' | '>' | '<=' | '>=' | 'LIKE';

// Define a type representing SQL conditions
type SQLCondition<T extends string> = {
  field: T;
  operator: SQLOperator;
  value: string;
};

// Define a type representing SQL query options
type SQLOptions<T extends string> = {
  select: string[];
  from: T;
  where?: SQLCondition<T>[];
};

// Define a type-level function to validate SQL conditions
type ValidateSQLCondition<T extends string, U extends SQLCondition<T>> = U['field'] extends keyof U
  ? U['operator'] extends SQLOperator
    ? U
    : never
  : never;

// Define a type-level function to validate SQL query options
type ValidateSQLOptions<T extends string> = {
  [K in keyof T]: T[K] extends string[] ? T[K] : never;
} extends {
  select: string[];
  from: string;
}
  ? SQLOptions<T>
  : never;

// Define a DSL for building SQL queries
class SQLQueryBuilder<T extends string> {
  private options: ValidateSQLOptions<T>;

  constructor(options: ValidateSQLOptions<T>) {
    this.options = options;
  }

  select(...fields: string[]): SQLQueryBuilder<T> {
    return new SQLQueryBuilder<T>({ ...this.options, select: fields });
  }

  from(table: T): SQLQueryBuilder<T> {
    return new SQLQueryBuilder<T>({ ...this.options, from: table });
  }

  where(condition: ValidateSQLCondition<T, SQLCondition<T>>): SQLQueryBuilder<T> {
    const conditions = this.options.where ? [...this.options.where, condition] : [condition];
    return new SQLQueryBuilder<T>({ ...this.options, where: conditions });
  }

  build(): string {
    const { select, from, where } = this.options;
    let query = `SELECT ${select.join(', ')} FROM ${from}`;
    if (where) {
      const whereClause = where.map(c => `${c.field} ${c.operator} '${c.value}'`).join(' AND ');
      query += ` WHERE ${whereClause}`;
    }
    return query;
  }
}

// Example usage
const query = new SQLQueryBuilder('users')
  .select('id', 'name')
  .from('users')
  .where({ field: 'age', operator: '>', value: '18' })
  .build();

console.log(query);

In this example:

We define types representing SQL operators (SQLOperator) and SQL conditions (SQLCondition).
We define a type-level function (ValidateSQLCondition) to validate SQL conditions against the expected structure.
We define a type-level function (ValidateSQLOptions) to validate SQL query options against the expected structure.
We implement a DSL for building SQL queries (SQLQueryBuilder) using generics and type-level computation to ensure correctness and type safety.
We demonstrate the usage of the DSL by constructing an SQL query with fluent syntax while enforcing type safety and correctness at compile time.

This DSL provides a high level of abstraction and type safety, ensuring that only valid SQL constructs are used when building queries. Type-level computation helps enforce constraints and ensures correctness in the DSL, providing a more robust and reliable solution for constructing SQL queries in TypeScript.

Configuration and Settings

Managing configuration settings and ensuring consistency and correctness across different parts of the application, such as environment-specific configurations or feature toggles.

// Define a type for environment names
type Environment = 'development' | 'staging' | 'production';

// Define a type-level function to validate environment variables
type ValidateEnv<T extends Environment> = T extends Environment
  ? (
    T extends 'development' ? (Required<DevelopmentConfig> & Partial<DevelopmentConfig>) :
    T extends 'staging' ? (Required<StagingConfig> & Partial<StagingConfig>) :
    T extends 'production' ? (Required<ProductionConfig> & Partial<ProductionConfig>) :
    never
  )
  : never;

// Define configuration types for different environments
interface DevelopmentConfig {
  apiUrl: string;
  databaseUrl: string;
  loggingEnabled: boolean;
}

interface StagingConfig {
  apiUrl: string;
  databaseUrl: string;
  loggingEnabled: boolean;
}

interface ProductionConfig {
  apiUrl: string;
  databaseUrl: string;
  loggingEnabled: boolean;
}

// Example usage
const environment: Environment = process.env.NODE_ENV as Environment;

// Validate environment variables based on the current environment
type CurrentConfig = ValidateEnv<typeof environment>;

// Get the current configuration based on the environment
const config: CurrentConfig = {
  apiUrl: process.env.API_URL!,
  databaseUrl: process.env.DATABASE_URL!,
  loggingEnabled: process.env.LOGGING_ENABLED === 'true',
};

// Validate required configuration values
if (!config.apiUrl || !config.databaseUrl) {
  throw new Error('Missing required environment variables.');
}

// Usage example
console.log('Current API URL:', config.apiUrl);
console.log('Current Database URL:', config.databaseUrl);
console.log('Logging Enabled:', config.loggingEnabled);

All that glitters is not gold: typelevel drawbacks

While type-level computation in TypeScript offers significant benefits in terms of type safety, correctness, and abstraction, it also comes with some drawbacks:

Complexity: Type-level computation often involves advanced features of the TypeScript type system, such as conditional types, mapped types, and type inference. This can lead to complex type definitions and code that is difficult to understand, especially for developers who are not familiar with advanced type system features.
Compile Time: As the complexity of type-level computation increases, so does the time it takes for TypeScript to compile the code. Large and complex type definitions can significantly slow down the compilation process, leading to longer build times, especially in large codebases.
Error Messages: Error messages generated by the TypeScript compiler for type-level computation errors can sometimes be cryptic and difficult to understand. Debugging type-related issues and diagnosing errors in complex type definitions can be challenging, especially for less experienced developers.
Tooling Support: While modern IDEs and text editors provide excellent support for TypeScript, including features like auto-completion, type checking, and type inference, they may struggle to provide accurate and helpful suggestions for code involving complex type-level computation.
Learning Curve: Understanding and effectively using type-level computation requires a solid understanding of TypeScript's type system and its advanced features. Developers who are new to TypeScript or who have limited experience with static typing may find it challenging to grasp the concepts and best practices related to type-level computation.
Maintenance: Complex type definitions used for type-level computation can be challenging to maintain over time, especially as codebases evolve and requirements change. Refactoring type definitions and ensuring they remain consistent and up-to-date with the rest of the codebase can require significant effort and careful attention to detail.

Who is the perfect audience for typelevel computation

Type-level development, especially in languages like TypeScript, is suitable for developers who prioritize type safety, correctness, and maintainability in their codebases. Here are some characteristics of the perfect audience for type-level development:

Type Safety Advocates: Developers who value strong type systems and strive to catch errors at compile time rather than runtime. They appreciate the benefits of static type checking for improving code quality and reducing bugs.
Large-Scale Projects: Developers working on large-scale projects with complex requirements and a need for robust architecture. Type-level development helps manage complexity and ensures code correctness, making it ideal for such projects.
Library and Framework Authors: Developers who create libraries, frameworks, or APIs for others to use. Type-level development allows them to provide better type definitions, improving the developer experience for consumers of their libraries.
Teams Emphasizing Code Quality: Development teams that prioritize code quality, maintainability, and long-term sustainability. Type-level development encourages best practices, such as code consistency, documentation, and adherence to architectural patterns.
Functional Programming Enthusiasts: Developers familiar with functional programming concepts and techniques. Type-level development often aligns well with functional programming principles, such as immutability, purity, and compositionality.
Tooling and IDE Users: Developers who rely on modern IDEs and text editors with strong TypeScript support. Type-level development leverages IDE features like auto-completion, type inference, and type checking to enhance productivity.
Continuous Integration and Deployment (CI/CD) Practitioners: Developers who use CI/CD pipelines for automated testing, builds, and deployments. Type-level development facilitates early error detection and reduces the risk of introducing bugs during deployment.
TypeScript Experts: Developers with a deep understanding of TypeScript's type system and its advanced features. Type-level development requires familiarity with concepts like conditional types, mapped types, generics, and type inference.
Codebase Maintainability Advocates: Developers who prioritize codebase maintainability and seek to reduce technical debt over time. Type-level development encourages clean, understandable code that is easier to maintain and refactor.
Enthusiastic Learners: Developers eager to explore new techniques and improve their skills. Type-level development offers opportunities to delve into advanced TypeScript concepts and expand one's knowledge of software development.

Overall, the perfect audience for type-level development comprises developers and teams who value type safety, code quality, and maintainability, and who are willing to invest in learning and applying advanced TypeScript techniques to their projects.

Typelevel Typescript: A cheat sheet

michael matos — Sat, 04 May 2024 04:03:55 +0000

Type-level programming in TypeScript unlocks a realm of possibilities, leveraging the language's powerful type system to perform complex computations, validations, and transformations directly within the type system itself. By harnessing features such as generics, conditional types, mapped types, and more, developers can create sophisticated type-level abstractions that enforce constraints, ensure type safety, and enhance code correctness. What's truly remarkable is how TypeScript's type system approaches "Turing completeness," a concept from computability theory suggesting that a system can perform any computation that a Turing machine can. While TypeScript's type system isn't fully Turing complete, its expressive capabilities come remarkably close, allowing for the implementation of advanced type-level patterns and techniques. From modeling domain-specific constraints to building type-safe libraries and frameworks, type-level programming in TypeScript empowers developers to write more robust, reliable, and maintainable code, pushing the boundaries of what's possible within a statically-typed language.

Type-level programming in TypeScript involves using types as values and manipulating them to achieve various tasks at compile time. Here's an exhaustive list of elements and techniques commonly used in type-level programming in TypeScript:

Basic Types
Type Aliases
Interfaces
Unions and Intersections
Type Guards
Generics
Mapped Types
Conditional Types
Recursive Types
Index Types
Type Assertions
Template Literal Types
Discriminated Unions
Type Queries
Phantom Types
Example: typelevel addition

Basic Types

TypeScript's built-in primitive types such as number, string, boolean, null, undefined, object, symbol, bigint.

Type Aliases

Using the type keyword to create aliases for existing types, allowing for easier readability and reuse.

// Define a type alias for a tuple representing a 2D point
type Point = [number, number];

// Define a function that calculates the distance between two points
function calculateDistance(point1: Point, point2: Point): number {
    const [x1, y1] = point1;
    const [x2, y2] = point2;
    const dx = x2 - x1;
    const dy = y2 - y1;
    return Math.sqrt(dx * dx + dy * dy);
}

// Usage example
const pointA: Point = [0, 0];
const pointB: Point = [3, 4];
const distance = calculateDistance(pointA, pointB);
console.log(distance); // Output: 5

Interfaces

Defining structural types representing object shapes.

// Define an interface representing a user with a minimum age
interface User {
    name: string;
    age: number;
}

// Define a type-level constraint to ensure a user's age is at least 18
type AdultUser<T extends User> = T['age'] extends number ? (T['age'] extends infer Age ? Age extends number ? Age extends number & (Age >= 18) ? T : never : never : never : never);

// Define a function to create an adult user
function createAdultUser<T extends User>(user: AdultUser<T>): AdultUser<T> {
    return user;
}

// Usage example
const validUser = createAdultUser({ name: 'John', age: 25 }); // This is valid
const invalidUser = createAdultUser({ name: 'Alice', age: 17 }); // This will cause a type error

Unions and Intersections

Combining multiple types into one using | for union types and & for intersection types.

// Define two types
type Square = {
    sideLength: number;
};

type Circle = {
    radius: number;
};

// Create a union type
type Shape = Square | Circle;

// Usage
const square: Shape = {
    sideLength: 5
};

const circle: Shape = {
    radius: 3
};

Type Guards

Using type predicates (e.g., value is SomeType) to refine types within conditional statements.

// You can use the `typeof` operator to check the type of a variable at runtime.
function isNumber(x: any): x is number {
    return typeof x === "number";
}

const value: number | string = 42;

if (isNumber(value)) {
    // Within this block, TypeScript knows that 'value' is of type 'number'
    console.log(value.toFixed(2));
}

// The `instanceof` operator is used to check whether an object is an instance // of a specific class or constructor function.
class Dog {
    breed: string;
    constructor(breed: string) {
        this.breed = breed;
    }
}

function isDog(x: any): x is Dog {
    return x instanceof Dog;
}

const pet: Dog | Cat = new Dog("Labrador");

if (isDog(pet)) {
    // Within this block, TypeScript knows that 'pet' is of type 'Dog'
    console.log(pet.breed);
}

Generics

Writing reusable code that operates on different types by parameterizing them.

type Keys<T> = keyof T; // <---- <T>

// Usage
interface Person {
    name: string;
    age: number;
}

type PersonKeys = Keys<Person>; // PersonKeys is "name" | "age"

Mapped Types

Transforming existing types into new types using mapped types like Partial, Required, Readonly, etc.

Mapped types in TypeScript are a powerful feature that allows you to create new types by transforming the properties of an existing type. Mapped types are especially useful when you need to create new types based on the structure of existing ones, such as transforming all properties to be optional or readonly.

The syntax for mapped types involves iterating over the keys of an existing type and applying transformations to create a new type.

(mapped types and index types are syntactically similar but always remember that mapped types have the keyword 'in' in it)

Here's a basic example of a mapped type:

type Person = {
    name: string;
    age: number;
};

// Create a new type where all properties are optional
type PartialPerson = {
    [Key in keyof Person]?: Person[Key]; // <<-- beware of the keyword 'in'
};

// Usage
const partialPerson: PartialPerson = {}; // Valid: All properties are optional

In this example:

keyof Person retrieves the keys of the Person type, which are "name" and "age".
[Key in keyof Person] iterates over each key.
Person[Key] accesses the type of each property.

Mapped types support various transformations, including:

Making properties optional:

   type PartialPerson = {
       [Key in keyof Person]?: Person[Key];
   };

Making properties readonly:

   type ReadonlyPerson = {
       readonly [Key in keyof Person]: Person[Key];
   };

Making properties nullable:

   type NullablePerson = {
       [Key in keyof Person]: Person[Key] | null;
   };

Removing properties:

   type AgelessPerson = {
       [Key in keyof Person as Exclude<Key, "age">]: Person[Key];
   };

Mapped types are highly versatile and can be used to create new types based on complex transformations of existing types, providing a flexible way to define type variations in TypeScript.

Conditional Types

Conditional expressions within types to determine the resulting type based on a condition.

type TypeName<T> =
  T extends string ? "string" :
  T extends number ? "number" :
  T extends boolean ? "boolean" :
  T extends undefined ? "undefined" :
  T extends Function ? "function" :
  "object";

// Examples
type T0 = TypeName<string>;  // "string"
type T1 = TypeName<"hello">; // "string"
type T2 = TypeName<42>;      // "number"
type T3 = TypeName<true>;    // "boolean"
type T4 = TypeName<undefined>; // "undefined"
type T5 = TypeName<() => void>; // "function"
type T6 = TypeName<string[]>; // "object"

Recursive Types

Defining types that reference themselves, enabling the creation of recursive data structures.

interface TreeNode<T> {
    value: T;
    left?: TreeNode<T>;
    right?: TreeNode<T>;
}

// Usage
const tree: TreeNode<number> = {
    value: 1,
    left: {
        value: 2,
        left: {
            value: 4
        },
        right: {
            value: 5
        }
    },
    right: {
        value: 3
    }
};

Index Types

Accessing and manipulating properties of objects using index types (keyof, []).
(mapped types and index types are syntactically similar but always remember that mapped types have the keyword 'in' in it).

//String index signatures allow you to define a type for accessing properties by // string keys on an object.
interface Dictionary<T> {
    [key: string]: T;
}

// Usage
const dict: Dictionary<number> = {
    "a": 1,
    "b": 2,
    "c": 3
};

console.log(dict["a"]); // Output: 1


// Numeric index signatures allow you to define a type for accessing elements by // numeric keys on an array-like object.
interface NumericArray {
    [index: number]: number;
}

// Usage
const arr: NumericArray = [1, 2, 3];

console.log(arr[0]); // Output: 1

Type Assertions

Type assertion in TypeScript is a way to tell the compiler to treat a value as a specific type, regardless of its inferred type.

// Angle-bracket Syntax:
let someValue: any = "hello";
let strLength: number = (<string>someValue).length;

// As-Keyword Syntax:
let someValue: any = "hello";
let strLength: number = (someValue as string).length;

Template Literal Types

They allow you to create new types by concatenating or transforming string literal types using template string syntax.

With template literal types, you can perform string manipulations at the type level, enabling you to create more expressive and precise type definitions.

type Greeting = "Hello, " | "Hi, ";
type Name = "Alice" | "Bob";

type PersonalizedGreeting = `${Greeting}${Name}`; // "Hello, Alice" | "Hello, Bob" | "Hi, Alice" | "Hi, Bob"

Discriminated Unions

Using a common discriminant property to differentiate between members of a union type.

interface Square {
    kind: "square";
    size: number;
}

interface Rectangle {
    kind: "rectangle";
    width: number;
    height: number;
}

interface Circle {
    kind: "circle";
    radius: number;
}

type Shape = Square | Rectangle | Circle;

function area(shape: Shape): number {
    switch (shape.kind) {
        case "square":
            return shape.size * shape.size;
        case "rectangle":
            return shape.width * shape.height;
        case "circle":
            return Math.PI * shape.radius ** 2;
    }
}

Type Queries

Inspecting and extracting information about types using type queries (e.g., typeof, keyof, infer).

Type queries in TypeScript are expressions that refer to types defined in the codebase. They allow you to extract the type of a variable, property, or function parameter as a type literal.

Type queries are useful in situations where you need to obtain the type of a specific entity dynamically, especially when working with complex or generic types.

Here's how you can use type queries:

Variable Type Query: You can use type queries to refer to the type of a variable.

let x = { a: 1, b: "hello" };

// Type of 'x' is inferred as { a: number, b: string }
type XType = typeof x;

Property Type Query: Type queries can be used to refer to the type of a property in an object.

type Person = {
    name: string;
    age: number;
};

// Type of 'name' is inferred as string
type NameType = Person["name"];

Function Parameter Type Query: You can use type queries to refer to the type of a function parameter.

function greet(name: string) {
    console.log("Hello, " + name);
}

// Type of 'name' parameter in 'greet' function is inferred as string
type NameType = Parameters<typeof greet>[0];

Type Query with Classes and Interfaces: Type queries can also refer to the types defined within classes and interfaces.

interface Circle {
    radius: number;
    area(): number;
}

// Type of 'area' method in 'Circle' interface
type AreaFunction = Circle["area"];

Type Query with Infer Type queries are evaluated statically by the TypeScript compiler, meaning they are resolved during the compilation process and do not have any runtime impact. They provide a powerful mechanism for extracting and reusing type information within your codebase.

type ArrayElementType<T> = T extends (infer U)[] ? U : never;

// Example usage
type StringArray = Array<string>;
type NumberArray = Array<number>;

type ElementTypeOfStringArray = ArrayElementType<StringArray>; // ElementTypeOfStringArray is inferred as 'string'
type ElementTypeOfNumberArray = ArrayElementType<NumberArray>; // ElementTypeOfNumberArray is inferred as 'number'

/*
In this example, the `ArrayElementType` conditional type takes a generic type `T`. It checks whether `T` extends an array type `(infer U)[]`. If it does, it assigns the type of the array elements to the type variable `U` using `infer`. Otherwise, it returns `never`.
*/

Type Query with keyof The keyof keyword in TypeScript is a powerful operator that is used to produce a union type of all known, enumerable property keys of an object type. It allows you to extract the keys of an object as string or numeric literals, creating a union of these keys that you can then use in various contexts, such as indexing or creating new types.

interface Person {
    name: string;
    age: number;
    address: string;
}

type PersonKeys = keyof Person;

// PersonKeys is now "name" | "age" | "address"

Phantom Types

Phantom types are a type-level programming technique used to enforce certain constraints or invariants at compile-time. They involve using type parameters that don't directly participate in runtime behaviour but are used solely for type checking purposes. Phantom types are often used to track information or states within the type system.

// Phantom type representing a status
interface Status<T> {}

// Phantom type representing "active" status
interface Active extends Status<"active"> {}

// Phantom type representing "inactive" status
interface Inactive extends Status<"inactive"> {}

// User type with a phantom type parameter representing status
interface User<StatusType extends Status<any>> {
    id: number;
    name: string;
    status: StatusType;
}

// Function to activate a user
function activateUser(user: User<Inactive>): User<Active> {
    return { ...user, status: {} as Active };
}

// Function to deactivate a user
function deactivateUser(user: User<Active>): User<Inactive> {
    return { ...user, status: {} as Inactive };
}

// Example usage
const inactiveUser: User<Inactive> = { id: 1, name: "John", status: {} as Inactive };
const activeUser: User<Active> = activateUser(inactiveUser);
const deactivatedUser: User<Inactive> = deactivateUser(activeUser);

These elements provide a powerful foundation for type-level programming in TypeScript, enabling developers to express and enforce complex constraints, design robust APIs, and achieve safer and more maintainable codebases.

Example: typelevel addition

// Phantom type representing a number
interface Num<T extends number> {}

// Type-level addition function
type Add<A extends number, B extends number> =
    A extends 0
    ? B
    : Add<
        Num<A extends infer N ? N extends number ? N - 1 : never : never>,
        Num<B extends infer N ? N extends number ? N + 1 : never : never>
      >;

// Example usage
type Result = Add<2, 3>; // Result is 5

We define a phantom type Num<T> to represent a number.
We define a type-level addition function Add<A, B>. It's a recursive function that subtracts 1 from the first number (A) and adds 1 to the second number (B) until the first number becomes 0. This is done using conditional types and recursion.
The result of the addition is represented as the type of the phantom number after all recursive operations have been completed.

OOP poetry part III - behavioural patterns

michael matos — Wed, 01 May 2024 02:06:16 +0000

what are behavioural patterns in OODesign

Behavioural patterns in design patterns are concerned with communication between objects, how objects collaborate, and how responsibilities are distributed among them. They focus on the interaction patterns between objects and classes, rather than on the structure of the classes or objects themselves.

List of patterns

Chain of responsability
Command pattern
Iterator pattern
Mediator pattern
memento pattern
Oberserver pattern
State pattern
strategy pattern
template method pattern
Visitor pattern

Chain of responsability

In the world of objects, bound in code's embrace,
Lies a pattern, a concept, with intricate grace.
Chain of Responsibility, its name does declare,
A solution profound, to design's wear and tear.

At its heart, it holds the essence of delegation,
Passing requests along, without hesitation.
When a sender's request, seeks a handler's touch,
The chain springs to action, responding as such.

Imagine a system where commands take flight,
Through layers of objects, to reach their light.
Each link in the chain, bears its own duty,
Handling requests with care, swiftness, and beauty.

For reason it stands, with a purpose so clear,
To decouple senders and receivers, so dear.
Flexibility reigns, as responsibilities flow,
Adapting to changes, with a graceful, agile bow.

In logging systems, it finds its home,
Where messages travel, not alone.
From lowest to highest, or vice versa too,
The chain handles tasks, old and new.

In graphical user interfaces, it takes its place,
Responding to events, with effortless grace.
Buttons and menus, actions abound,
The chain ensures they're properly found.

In software pipelines, it proves its might,
Processing data streams, day and night.
Each link plays its role, in a symphony grand,
Chain of Responsibility, at its command.

In the realm of web servers, where requests flood the gate,
Express.js stands tall, amidst the debate.
With middleware galore, it handles each plea,
Chain of Responsibility, it sets users free.

From parsing requests to serving static files,
Express delegates tasks with practiced smiles.
Routing requests, with paths clear and bright,
Each middleware link, guiding with might.

Authentication, logging, error handling too,
Express.js weaves them seamlessly through.
Each middleware layer, a link in the chain,
Ensuring requests don't fall in vain.

So here's to the pattern, ingenious and bright,
Weaving through systems, like stars in the night.
With elegance it solves, design's intricate chore,
Chain of Responsibility, forevermore.

import express, { Request, Response, NextFunction } from 'express';

// Define a middleware function for logging
function loggerMiddleware(req: Request, res: Response, next: NextFunction) {
    console.log(`[${new Date().toISOString()}] ${req.method} ${req.path}`);
    next(); // Pass control to the next middleware
}

// Define a middleware function for authentication
function authMiddleware(req: Request, res: Response, next: NextFunction) {
    const authToken = req.headers.authorization;

    if (!authToken || authToken !== 'secret_token') {
        return res.status(401).send('Unauthorized');
    }

    next(); // Pass control to the next middleware
}

// Define a route handler
function homeRouteHandler(req: Request, res: Response) {
    res.send('Welcome to the home page!');
}

// Create an Express application
const app = express();

// Register middleware in the chain
app.use(loggerMiddleware);
app.use(authMiddleware);

// Define a route for the home page
app.get('/', homeRouteHandler);

// Start the server
const PORT = 3000;
app.listen(PORT, () => {
    console.log(`Server is running on http://localhost:${PORT}`);
});

Command pattern

In the vast realm of code, where structures abound,
Lies a pattern of power, with elegance crowned.
Command Design Pattern, its name whispers grace,
A solution profound, to design's complex maze.

At its core, it holds the essence of action,
Encapsulating tasks with flawless traction.
When a request seeks execution's embrace,
The command pattern steps in, with unwavering grace.

Picture a system where commands take flight,
Bound in objects, gleaming with light.
Each command encapsulates an action's delight,
Decoupling sender and receiver in design's sight.

For its purpose it stands, with clarity so clear,
To separate concerns, dispelling design's fear.
Flexibility reigns as tasks are enshrined,
In commands, where elegance and power entwined.

Amidst the realm of React's vibrant domain,
Where state management orchestrates without strain,
Redux, the sage, with its store's noble grace,
Embraces commands in a timeless embrace.

Within its core, actions spring to life,
Commands encapsulated, amidst the strife.
Each action a decree, a change to impart,
In Redux's world, a symphony's start.

As users interact with the UI's array,
Actions echo their intent, clear as day.
From clicks to inputs, each event unfurled,
Triggers a command, in the Redux world.

Through reducers and dispatch, the commands take flight,
Altering state with precision, might.
Each action a ripple, in React's gentle breeze,
Guiding the flow, with effortless ease.

So here's to the pattern, with purpose so grand,
Command Design Pattern, across the land.
In software's tapestry, it weaves its tale,
A masterpiece of design, without fail.

// CounterActions.js
export const ActionTypes = {
  INCREMENT: 'INCREMENT',
  DECREMENT: 'DECREMENT',
};

// Action creators (commands)
export const increment = () => ({
  type: ActionTypes.INCREMENT,
});

export const decrement = () => ({
  type: ActionTypes.DECREMENT,
});

// CounterReducer.js
import { ActionTypes } from './CounterActions';

const initialState = {
  count: 0,
};

// Reducer function
const counterReducer = (state = initialState, action) => {
  switch (action.type) {
    case ActionTypes.INCREMENT: // Command: INCREMENT
      return {
        ...state,
        count: state.count + 1,
      };
    case ActionTypes.DECREMENT: // Command: DECREMENT
      return {
        ...state,
        count: state.count - 1,
      };
    default:
      return state;
  }
};

export default counterReducer;

// Counter.js
import React, { useReducer } from 'react';
import counterReducer from './CounterReducer';
import { increment, decrement } from './CounterActions';

const Counter = () => {
  // Initialize state and dispatch function using useReducer hook
  const [state, dispatch] = useReducer(counterReducer, { count: 0 });

  // Command execution: Dispatching actions
  const handleIncrement = () => {
    dispatch(increment()); // Command: increment
  };

  const handleDecrement = () => {
    dispatch(decrement()); // Command: decrement
  };

  return (
    <div>
      <h1>Counter: {state.count}</h1>
      {/* Buttons triggering commands */}
      <button onClick={handleIncrement}>Increment</button>
      <button onClick={handleDecrement}>Decrement</button>
    </div>
  );
};

export default Counter;

Iterator pattern

In the world of data, where structures abound,
A pattern emerges, with purpose profound.
Iterator Pattern, its essence does gleam,
Navigating collections like a serene dream.

At its heart lies the quest to explore,
Traversing sequences, from ceiling to floor.
When data beckons, and elements call,
Iterator responds, ensuring naught shall stall.

Imagine a journey through lists long and wide,
With each step traversed, with grace as our guide.
From start to end, or reverse if we please,
Iterator leads, with consummate ease.

Its purpose to abstract, traversal's chore,
From arrays to trees, and even more.
Flexibility reigns, as it adapts with flair,
To various structures, without a care.

In for loops, it finds its natural place,
Where iteration flows, at a steady pace.
Looping through arrays, in languages vast,
Iterator ensures no element's surpassed.

In the realm of streams, both finite and grand,
Iterator's hand guides across the land.
From reading files to parsing streams,
Iterator orchestrates, fulfilling our dreams.

So here's to the pattern, in data's embrace,
Iterator Pattern, with elegance and grace.
In software's symphony, it plays its part,
A maestro of traversal, with a beating heart.

// Define an interface for the iterator
interface Iterator<T> {
  next(): { value: T, done: boolean };
}

// Define an iterable collection for Fibonacci numbers
class FibonacciSequence implements Iterable<number> {
  [Symbol.iterator](): Iterator<number> {
    let a = 0;
    let b = 1;

    // Implement the next method of the iterator
    const next = (): { value: number, done: boolean } => {
      const value = a;
      a = b;
      b = value + b;
      return { value, done: false };
    };

    return { next };
  }
}

// Example usage
const fibonacciSequence = new FibonacciSequence();
const iterator = fibonacciSequence[Symbol.iterator]();

// Print the first 10 Fibonacci numbers
for (let i = 0; i < 10; i++) {
  const result = iterator.next();
  console.log(result.value); // Output: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34
}

Mediator pattern

In the world of software, where systems intertwine,
There lies a pattern, with a purpose divine.
Mediator, its name, a conductor of grace,
Bringing harmony to every place.

At its core, it serves to mediate,
Between components, a bridge so great.
With elegance and finesse, it orchestrates,
Communication between disparate states.

Imagine a world where chaos reigns,
Components scattered, with no chains.
Mediator steps in, with a calming embrace,
Bringing order to the chaotic space.

Consider a complex form, with fields galore,
Each input, a component, longing to explore.
But how do they converse, how do they share,
The data they hold, with such care?

Enter the Mediator, with its guiding light,
Centralizing state, keeping components in sight.
Through events and callbacks, it fosters a link,
Between form elements, without a kink.

From Backbone to React, and frameworks in between,
Mediator's touch can always be seen.
Facilitating communication, without fuss,
Bringing cohesion to applications, without muss.

So here's to the Mediator, so noble and grand,
A pattern that brings order to every land.
In software's symphony, it plays its part,
Bringing harmony and unity from the start.

import React, { createContext, useContext, useState } from 'react';

// Define a Context to act as the Mediator
const DataContext = createContext();

// Define a DataProvider component to manage state and act as the Mediator
const DataProvider = ({ children }) => {
  // State variable managed by the DataProvider
  const [data, setData] = useState('Initial data');

  // Method to update data
  const updateData = (newData) => {
    setData(newData);
  };

  // Context value containing data and methods to update it
  const contextValue = {
    data,
    updateData,
  };

  return <DataContext.Provider value={contextValue}>{children}</DataContext.Provider>;
};

// Custom hook to access the DataContext
const useDataContext = () => useContext(DataContext);

// Child component consuming the DataContext and displaying the data
const DisplayComponent = () => {
  // Access context variable using custom hook
  const { data } = useDataContext();

  return <p>Data from context: {data}</p>;
};

// Child component consuming the DataContext and updating the data
const UpdateComponent = () => {
  // Access context variable and update method using custom hook
  const { data, updateData } = useDataContext();

  // Handler for updating data
  const handleUpdate = () => {
    const newData = 'Updated data';
    updateData(newData); // Call the updateData method from the context
  };

  return (
    <div>
      <p>Data from context: {data}</p>
      <button onClick={handleUpdate}>Update Data</button>
    </div>
  );
};

// Parent component providing the DataContext to its children
const ParentComponent = () => {
  return (
    <DataProvider>
      <div>
        <h2>Parent Component</h2>
        <p>This component provides data to its children through the DataContext.</p>
        <DisplayComponent /> {/* Child component displaying the data */}
        <UpdateComponent /> {/* Child component updating the data */}
      </div>
    </DataProvider>
  );
};

export default ParentComponent;

memento pattern

In the land where code takes flight,
Lies a pattern of memory, shining bright.
Known as Memento, its purpose grand,
To capture states with a gentle hand.

When objects dance with transient grace,
And their states must leave no trace,
Memento whispers, "Fear not, dear friend,
For I shall hold your states till journey's end."

In times of undo, where mistakes do roam,
Memento's embrace brings solace home.
With each command to rewind or revise,
It restores the past before our eyes.

In editors where text flows free,
Undoing changes is a jubilee.
Memento preserves each edit's story,
Returning text to its former glory.

In games where players quest and fight,
Memento records each hero's plight.
With checkpoints saved at every stage,
Players can rewind to a safer page.

In applications of financial might,
Where transactions move with speed and light,
Memento safeguards each transaction's trail,
Ensuring data integrity shall never fail.

So here's to Memento, steadfast and true,
In the world of patterns, it shines anew.
With its purpose clear and its use cases vast,
It guards our states, ensuring they last.

// Originator: Represents the text editor
class TextEditor {
  private content: string;

  constructor() {
    this.content = '';
  }

  // Method to set the content of the text editor
  setContent(content: string) {
    this.content = content;
  }

  // Method to get the content of the text editor
  getContent(): string {
    return this.content;
  }

  // Method to create a memento (snapshot) of the current state
  createMemento(): Memento {
    return new Memento(this.content);
  }

  // Method to restore the state from a memento
  restoreFromMemento(memento: Memento) {
    this.content = memento.getState();
  }
}

// Memento: Represents the snapshot of the state of the text editor
class Memento {
  private state: string;

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

  // Method to get the state from the memento
  getState(): string {
    return this.state;
  }
}

// Caretaker: Manages the history of the text editor's states
class HistoryManager {
  private history: Memento[];
  private currentIndex: number;

  constructor() {
    this.history = [];
    this.currentIndex = -1;
  }

  // Method to add a memento to the history
  addMemento(memento: Memento) {
    // Clear future history when adding a new state
    this.history.splice(this.currentIndex + 1);
    this.history.push(memento);
    this.currentIndex++;
  }

  // Method to undo the last change
  undo(): Memento | null {
    if (this.currentIndex > 0) {
      this.currentIndex--;
      return this.history[this.currentIndex];
    }
    return null;
  }

  // Method to redo the last undone change
  redo(): Memento | null {
    if (this.currentIndex < this.history.length - 1) {
      this.currentIndex++;
      return this.history[this.currentIndex];
    }
    return null;
  }
}

// Usage example
const editor = new TextEditor();
const historyManager = new HistoryManager();

// Initial content
editor.setContent('Hello, world!');

// Save initial state
const initialState = editor.createMemento();
historyManager.addMemento(initialState);

// User makes changes
editor.setContent('Hello, universe!');
const currentState = editor.createMemento();
historyManager.addMemento(currentState);

// Undo the last change
const undoneState = historyManager.undo();
if (undoneState) {
  editor.restoreFromMemento(undoneState);
}

console.log(editor.getContent()); // Output: Hello, world!

// Redo the undone change
const redoneState = historyManager.redo();
if (redoneState) {
  editor.restoreFromMemento(redoneState);
}

console.log(editor.getContent()); // Output: Hello, universe!

Oberserver pattern

In the realm where patterns weave their tale,
Lies one of observation, never frail.
'Tis the Observer, its purpose clear,
To let objects know when changes draw near.

When entities dance in a state of flux,
Observer stands ready, never to duck.
Its eyes keenly watch, its ears attuned,
To signals of change, it's always tuned.

In UIs where buttons click and fields update,
Observer whispers softly, "No need to debate."
It notifies listeners when data's transformed,
Ensuring views reflect the changes performed.

In chatrooms where messages fly,
Observer ensures each user's cry.
It broadcasts updates to all who listen,
Uniting users in a shared vision.

In games where scores rise and heroes fall,
Observer shouts loud, heeding the call.
It notifies players of events unseen,
Guiding them through each digital scene.

In the world of Node.js, Observer takes flight,
Within event-driven architecture, it finds its might.
As Node.js dances in asynchronous glee,
Observer notifies listeners of events, setting data free.

In Vue.js, Observer finds a home,
Within the reactive core, it's free to roam.
With reactivity at its heart, Vue.js shines,
Observer pattern ensures views update in time.

In Node.js, event emitters reign supreme,
From HTTP requests to file streams, it's a dream.
Observer pattern orchestrates the flow,
Notifying subscribers when events bestow.

In Vue.js, components come alive,
As data changes, they strive to thrive.
With Observer pattern, they stay in sync,
Rendering views as states blink.

So here's to Node.js and Vue.js, champions bold,
Implementing Observer, their stories unfold.
In event-driven and reactive lands they dwell,
Observer pattern ensures all is well.

// Observer interface defining the contract for observers
interface Observer {
  update(data: any): void;
}

// Observable (subject) class that emits events to observers
class Observable {
  private observers: Observer[] = [];

  // Method to subscribe an observer to the observable
  subscribe(observer: Observer) {
    this.observers.push(observer);
  }

  // Method to unsubscribe an observer from the observable
  unsubscribe(observer: Observer) {
    this.observers = this.observers.filter(obs => obs !== observer);
  }

  // Method to notify all observers when an event occurs
  notify(data: any) {
    this.observers.forEach(observer => observer.update(data));
  }
}

// Concrete observer class implementing the Observer interface
class ConcreteObserver implements Observer {
  update(data: any) {
    console.log('Received data:', data);
  }
}

// Usage example
const observable = new Observable();
const observer1 = new ConcreteObserver();
const observer2 = new ConcreteObserver();

// Subscribe observers to the observable
observable.subscribe(observer1);
observable.subscribe(observer2);

// Notify observers when an event occurs
observable.notify('Event 1');
observable.notify('Event 2');

// Unsubscribe observer1 from the observable
observable.unsubscribe(observer1);

// Notify observers again
observable.notify('Event 3');

State pattern

In the realm of software, where patterns are found,
There's one called State, its purpose profound.
Managing objects in various states they may be,
Guiding their behavior with flexibility.

When objects transition from one state to the next,
State pattern ensures they're never perplexed.
It encapsulates state-specific behavior in classes,
Allowing objects to switch with minimal fuss.

In vending machines, where snacks await,
State pattern controls each coin's fate.
As users insert coins and make their selection,
State pattern governs with flawless direction.

In game development, where characters roam,
State pattern gives them a place to call home.
From "idle" to "running", from "jumping" to "crouching",
State pattern keeps their movements from slouching.

In traffic lights, where signals dictate,
State pattern orchestrates the flow of each rate.
From "red" to "green", from "stop" to "go",
State pattern ensures traffic's ebb and flow.

In the software's expanse, where complexity unfurls,
State pattern maps out the intricate worlds.
From states of "ready" to "waiting" and "done",
Each transition managed, each victory won.

In the realm of eCommerce, where orders take flight,
State pattern tracks them from "placed" to "shipped" in the night.
With states like "processing" and "delivered" in sight,
Smooth transitions ensure customers' delight.

In the domain of gaming, where characters roam,
State pattern guides them to their digital home.
From "idle" to "running", from "attacking" to "flee",
Each state transition ensures the game's flow is free.

In the maze of workflows, where tasks intertwine,
State pattern choreographs each step in line.
From "pending" to "approved", from "rejected" to "complete",
Efficient transitions make processes neat.

Within React's realm, where data is king,
State pattern reigns supreme, like a golden ring.
With each fetch request to the server's domain,
State pattern manages the data's gain.

From "loading" to "success" and "error" in sight,
State pattern orchestrates, ensuring all is right.
As components await data to display,
State pattern handles each state, come what may.

So here's to State pattern, with its purpose clear,
Managing objects' states without fear.
In software's vast landscape, it finds its place,
Guiding objects with elegance and grace.

import React, { useState, useEffect } from 'react';

// Define the possible states for the fetch
const FetchState = {
  Loading: 'loading',
  Success: 'success',
  Error: 'error',
};

// Define the fetch component
const FetchComponent = ({ url }) => {
  const [fetchState, setFetchState] = useState({
    state: FetchState.Loading,
    data: null,
    error: '',
  });

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await fetch(url);
        const data = await response.json();
        setFetchState({ state: FetchState.Success, data, error: '' });
      } catch (error) {
        setFetchState({ state: FetchState.Error, data: null, error: error.message });
      }
    };

    fetchData();

    // Cleanup function
    return () => {
      // Cleanup logic if needed
    };
  }, [url]);

  return (
    <div>
      {fetchState.state === FetchState.Loading && <p>Loading...</p>}
      {fetchState.state === FetchState.Success && <p>Data: {JSON.stringify(fetchState.data)}</p>}
      {fetchState.state === FetchState.Error && <p>Error: {fetchState.error}</p>}
    </div>
  );
};

// Usage example
const App = () => {
  return (
    <div>
      <h1>Fetch Component Example</h1>
      <FetchComponent url="https://jsonplaceholder.typicode.com/posts/1" />
    </div>
  );
};

export default App;

strategy pattern

In the realm of software, where patterns take flight,
Lies one called Strategy, a beacon of light.
With purpose profound, it shapes algorithms' course,
Guiding their behavior with elegant force.

In the heart of the code, where complexity lies,
Strategy pattern simplifies, like clear, open skies.
It encapsulates algorithms with finesse,
Allowing them to vary, adapt, and impress.

When sorting arrays or searching for keys,
Strategy pattern shines, like a cool breeze.
With algorithms swapped at runtime's command,
Complex tasks are tamed, and code becomes grand.

In games where strategies govern each move,
Strategy pattern guides, ensuring they groove.
From AI opponents to player tactics grand,
Dynamic strategies shape the game's hand.

In eCommerce realms where discounts are sought,
Strategy pattern aids, with benefits brought.
From fixed discounts to percentage rates,
Flexible strategies handle the rates.

In user interfaces where validations reign,
Strategy pattern steps in, removing the pain.
From email validations to password checks,
Custom strategies ensure security's specs.

So here's to Strategy, with its purpose clear,
In software's vast landscape, it's held dear.
From sorting algorithms to game AI,
Strategy pattern guides with a knowing eye.

example uno:

const numbers = [4, 2, 5, 1, 3];

// Sort in ascending order using the default comparison
const ascendingOrder = numbers.sort((a, b) => a - b);
console.log(ascendingOrder); // Output: [1, 2, 3, 4, 5]

// Sort in descending order using a custom comparison
const descendingOrder = numbers.sort((a, b) => b - a);
console.log(descendingOrder); // Output: [5, 4, 3, 2, 1]

example numero deux(a bit more complex):

// Define the interface for sorting strategies
interface SortStrategy {
  sort(data: any[]): any[];
}

// Define concrete sorting strategies
class BubbleSortStrategy implements SortStrategy {
  sort(data: any[]): any[] {
    // Bubble sort implementation
    return data.slice().sort((a, b) => a - b);
  }
}

class QuickSortStrategy implements SortStrategy {
  sort(data: any[]): any[] {
    // Quick sort implementation
    const quickSort = (arr: any[]): any[] => {
      if (arr.length <= 1) return arr;
      const pivot = arr[arr.length - 1];
      const left = [];
      const right = [];
      for (let i = 0; i < arr.length - 1; i++) {
        if (arr[i] < pivot) left.push(arr[i]);
        else right.push(arr[i]);
      }
      return [...quickSort(left), pivot, ...quickSort(right)];
    };
    return quickSort(data);
  }
}

class MergeSortStrategy implements SortStrategy {
  sort(data: any[]): any[] {
    // Merge sort implementation
    const merge = (left: any[], right: any[]): any[] => {
      const result = [];
      let leftIndex = 0;
      let rightIndex = 0;
      while (leftIndex < left.length && rightIndex < right.length) {
        if (left[leftIndex] < right[rightIndex]) {
          result.push(left[leftIndex]);
          leftIndex++;
        } else {
          result.push(right[rightIndex]);
          rightIndex++;
        }
      }
      return result.concat(left.slice(leftIndex)).concat(right.slice(rightIndex));
    };

    const mergeSort = (arr: any[]): any[] => {
      if (arr.length <= 1) return arr;
      const middle = Math.floor(arr.length / 2);
      const left = arr.slice(0, middle);
      const right = arr.slice(middle);
      return merge(mergeSort(left), mergeSort(right));
    };

    return mergeSort(data);
  }
}

class SelectionSortStrategy implements SortStrategy {
  sort(data: any[]): any[] {
    // Selection sort implementation
    const selectionSort = (arr: any[]): any[] => {
      const len = arr.length;
      for (let i = 0; i < len - 1; i++) {
        let min = i;
        for (let j = i + 1; j < len; j++) {
          if (arr[j] < arr[min]) {
            min = j;
          }
        }
        if (min !== i) {
          [arr[i], arr[min]] = [arr[min], arr[i]];
        }
      }
      return arr;
    };
    return selectionSort(data.slice());
  }
}

class InsertionSortStrategy implements SortStrategy {
  sort(data: any[]): any[] {
    // Insertion sort implementation
    const insertionSort = (arr: any[]): any[] => {
      const len = arr.length;
      for (let i = 1; i < len; i++) {
        let j = i;
        const temp = arr[i];
        while (j > 0 && arr[j - 1] > temp) {
          arr[j] = arr[j - 1];
          j--;
        }
        arr[j] = temp;
      }
      return arr;
    };
    return insertionSort(data.slice());
  }
}

// Define the context class
class SortContext {
  private strategy: SortStrategy;

  constructor(strategy: SortStrategy) {
    this.strategy = strategy;
  }

  // Method to set the sorting strategy
  setStrategy(strategy: SortStrategy) {
    this.strategy = strategy;
  }

  // Method to perform sorting using the current strategy
  sort(data: any[]): any[] {
    return this.strategy.sort(data);
  }
}

// Usage example
const data = [7, 2, 5, 1, 3, 9, 4, 6, 8];

const bubbleSort = new BubbleSortStrategy();
const quickSort = new QuickSortStrategy();
const mergeSort = new MergeSortStrategy();
const selectionSort = new SelectionSortStrategy();
const insertionSort = new InsertionSortStrategy();

const context = new SortContext(bubbleSort);
console.log('Bubble Sort:', context.sort(data));

context.setStrategy(quickSort);
console.log('Quick Sort:', context.sort(data));

context.setStrategy(mergeSort);
console.log('Merge Sort:', context.sort(data));

context.setStrategy(selectionSort);
console.log('Selection Sort:', context.sort(data));

context.setStrategy(insertionSort);
console.log('Insertion Sort:', context.sort(data));

template method pattern

In software's realm where patterns dance,
Lies one called Template, with elegance and chance.
With purpose clear, it shapes the flow,
Guiding methods with a steadfast glow.

In the heart of libraries, where frameworks shine,
Template Method pattern orchestrates, a design so fine.
With hooks and lifecycle methods in its hand,
It crafts the structure, like grains of sand.

Mocha, the testing framework of choice,
Relies on Template, with a confident voice.
Test suites and cases, in patterns arrayed,
Execute with precision, like a serenade.

Webpack, the bundler that packs with might,
Utilizes Template, in its flight.
Plugins and loaders, with methods defined,
Extend its capabilities, in a bind.

And in the world of JavaScript's delight,
Template Method pattern shines so bright.
In libraries and frameworks, it finds its place,
Guiding developers with its grace.

// Abstract class defining the template method
abstract class DataProcessor {
  // Template method defining the overall algorithm
  process(data: any[]): void {
    this.readData(data);
    this.transformData(data);
    this.writeData(data);
  }

  // Abstract methods to be implemented by subclasses
  abstract readData(data: any[]): void;
  abstract transformData(data: any[]): void;
  abstract writeData(data: any[]): void;
}

// Concrete subclass implementing the template method
class JSONDataProcessor extends DataProcessor {
  readData(data: any[]): void {
    console.log('Reading JSON data:', data);
  }

  transformData(data: any[]): void {
    console.log('Transforming JSON data...');
    // Perform transformation logic specific to JSON data
  }

  writeData(data: any[]): void {
    console.log('Writing JSON data:', data);
  }
}

// Concrete subclass implementing the template method
class CSVDataProcessor extends DataProcessor {
  readData(data: any[]): void {
    console.log('Reading CSV data:', data);
  }

  transformData(data: any[]): void {
    console.log('Transforming CSV data...');
    // Perform transformation logic specific to CSV data
  }

  writeData(data: any[]): void {
    console.log('Writing CSV data:', data);
  }
}

// Usage example
const jsonDataProcessor = new JSONDataProcessor();
jsonDataProcessor.process([{ id: 1, name: 'John' }, { id: 2, name: 'Doe' }]);

const csvDataProcessor = new CSVDataProcessor();
csvDataProcessor.process(['1,John', '2,Doe']);

Visitor pattern

In the tapestry of code, where patterns reside,
Lies one called Visitor, with methods to guide.
With purpose profound, it traverses with grace,
Visiting objects, in a coded embrace.

In compilers and parsers, it finds its abode,
Navigating syntax, along the code road.
Each node in the tree, a visit it pays,
Transforming structures, in myriad ways.

In virtual doms of libraries grand,
Visitor pattern takes a stand.
Traversing elements, with DOM's might,
Manipulating, in the web's light.

In data structures of complex design,
Visitor pattern's use, truly shines.
From trees to graphs, it roams with glee,
Performing tasks, with strategy.

So here's to Visitor, with its journey vast,
Guiding traversals, from first to last.
In software's landscape, it leaves its mark,
A pattern of power, in the coder's arc.

uno:

// Babel Visitor implementation
const babelVisitor = {
  // Visits ArrowFunctionExpression nodes
  ArrowFunctionExpression(node, state) {
    // Transform ArrowFunctionExpression nodes
    // For example, we might want to convert arrow functions to regular functions
    // (This is just a simplified example)
    const newFunctionExpression = {
      type: 'FunctionExpression',
      params: node.params,
      body: node.body,
      generator: false,
      async: false
    };
    return newFunctionExpression;
  },

  // Visits CallExpression nodes
  CallExpression(node, state) {
    // Transform CallExpression nodes
    // For example, we might want to prepend a console.log statement before each function call
    // (This is just a simplified example)
    const newCallExpression = {
      type: 'CallExpression',
      callee: {
        type: 'MemberExpression',
        object: { type: 'Identifier', name: 'console' },
        property: { type: 'Identifier', name: 'log' }
      },
      arguments: [
        { type: 'StringLiteral', value: 'Calling function:', raw: '"Calling function:"' },
        node
      ]
    };
    return newCallExpression;
  }
};

// Babel plugin using the Visitor pattern
const babelPlugin = ({ types: t }) => {
  return {
    visitor: babelVisitor
  };
};

// Using Babel with the plugin
const babel = require('@babel/core');

const inputCode = `const add = (a, b) => { return a + b; }; console.log(add(2, 3));`;
const output = babel.transformSync(inputCode, {
  plugins: [babelPlugin]
});

console.log(output.code);

dos:

// Visitor for generating HTML markup
class HTMLGeneratorVisitor {
  constructor() {
    this.html = '';
  }

  visitParagraph(paragraph) {
    this.html += `<p>${paragraph.content}</p>`;
  }

  visitImage(image) {
    this.html += `<img src="${image.src}" alt="${image.alt}">`;
  }

  visitHyperlink(hyperlink) {
    this.html += `<a href="${hyperlink.url}">${hyperlink.text}</a>`;
  }
}

// Element representing a paragraph in the document
class ParagraphElement {
  constructor(content) {
    this.content = content;
  }

  accept(visitor) {
    visitor.visitParagraph(this);
  }
}

// Element representing an image in the document
class ImageElement {
  constructor(src, alt) {
    this.src = src;
    this.alt = alt;
  }

  accept(visitor) {
    visitor.visitImage(this);
  }
}

// Element representing a hyperlink in the document
class HyperlinkElement {
  constructor(url, text) {
    this.url = url;
    this.text = text;
  }

  accept(visitor) {
    visitor.visitHyperlink(this);
  }
}

// Example document
const documentElements = [
  new ParagraphElement('This is a paragraph.'),
  new ImageElement('image.jpg', 'Image Alt Text'),
  new HyperlinkElement('https://example.com', 'Example Website')
];

// Create a visitor instance
const htmlGeneratorVisitor = new HTMLGeneratorVisitor();

// Traverse the document elements using the visitor
documentElements.forEach(element => element.accept(htmlGeneratorVisitor));

// Output the generated HTML
console.log(htmlGeneratorVisitor.html);

/*
<p>This is a paragraph.
</p><img src="image.jpg" alt="Image Alt Text">
<a href="https://example.com">Example Website</a>
*/

FIN

OOP poetry Part II: structural patterns

michael matos — Tue, 30 Apr 2024 00:47:07 +0000

what are structural patterns in OODesign

Structural patterns are a category of design patterns that focus on how classes and objects are composed to form larger structures. These patterns help in organizing relationships between different components to make the system more manageable, flexible, and efficient. Structural patterns primarily deal with class composition and object composition.

List of patterns

Adapter pattern
Bridge pattern
Decorator pattern
Facade pattern
Proxy pattern
Composite pattern
Flywieght pattern or Pool pattern

Adapter pattern

In the realm of code where patterns thrive,
There's one that keeps our designs alive.
It's the adapter, a clever guise,
In software's world, it truly flies.

Imagine systems of varied kind,
Their interfaces not aligned.
Yet, in the dance of tech's grand play,
They must communicate, find a way.

Enter the adapter, with its artful grace,
Linking the old with the new in space.
It wraps the incompatible with care,
Making connections where none would dare.

Like a bridge across a vast divide,
It helps two worlds harmonize.
With its form, the old can still converse,
In the language of the universe.

From legacy to the avant-garde,
The adapter pattern plays its card.
It transforms, it molds, it adapts with glee,
Bringing cohesion where there once was spree.

So let's raise our keyboards, give a cheer,
For the adapter pattern, always near.
In the symphony of code's grand scheme,
It's the harmony that makes us dream.

// Adaptee: Temperature sensor data
class TemperatureSensor {
    constructor(private temperature: number) {}

    getTemperature(): number {
        return this.temperature;
    }
}

// Adaptee: Humidity sensor data
class HumiditySensor {
    constructor(private humidity: number) {}

    getHumidity(): number {
        return this.humidity;
    }
}

// Target: Interface expected by the client (JSON format)
interface JSONData {
    toJSON(): object;
}

// Adapter: Adapts TemperatureSensor data to JSONData
class TemperatureSensorToJSONAdapter implements JSONData {
    constructor(private temperatureSensor: TemperatureSensor) {}

    toJSON(): object {
        return {
            type: "Temperature",
            value: this.temperatureSensor.getTemperature(),
            unit: "Celsius"
        };
    }
}

// Adapter: Adapts HumiditySensor data to JSONData
class HumiditySensorToJSONAdapter implements JSONData {
    constructor(private humiditySensor: HumiditySensor) {}

    toJSON(): object {
        return {
            type: "Humidity",
            value: this.humiditySensor.getHumidity(),
            unit: "Percentage"
        };
    }
}

// Client code
function convertToJSON(data: JSONData) {
    return data.toJSON();
}

// Usage
const temperatureSensorData = new TemperatureSensor(25); // 25°C
const humiditySensorData = new HumiditySensor(50); // 50% humidity

const temperatureJSONAdapter = new TemperatureSensorToJSONAdapter(temperatureSensorData);
const humidityJSONAdapter = new HumiditySensorToJSONAdapter(humiditySensorData);

const temperatureJSON = convertToJSON(temperatureJSONAdapter);
const humidityJSON = convertToJSON(humidityJSONAdapter);

console.log("Temperature Sensor Data:", temperatureJSON);
console.log("Humidity Sensor Data:", humidityJSON);

Bridge pattern

In the realm of patterns, there lies a gem,
A Bridge that spans a vast code realm.
With elegance and grace, it stands tall,
Linking concepts, preventing a fall.

Two worlds it binds, with care and precision,
Abstract and concrete in a harmonious vision.
On one side, abstraction reigns supreme,
A realm of ideas, like a waking dream.

On the other, implementation holds sway,
Details and intricacies in a complex array.
Yet, through the Bridge, they find a way to unite,
A symphony of code, shining bright.

With an interface as its guiding light,
The Bridge ensures both realms stay right.
Changes ripple through without a fuss,
Preserving order, without a muss.

So let us celebrate this pattern divine,
A testament to software's design.
For in the Bridge, we find a bridge of trust,
A link between worlds, built of code's lust.

// Implementor: Interface for device control
interface Device {
    powerOn(): void;
    powerOff(): void;
    setVolume(volume: number): void;
}

// Concrete Implementor: TV device
class TV implements Device {
    powerOn(): void {
        console.log("TV is powered on");
    }

    powerOff(): void {
        console.log("TV is powered off");
    }

    setVolume(volume: number): void {
        console.log(`TV volume set to ${volume}`);
    }
}

// Concrete Implementor: DVD player device
class DVDPlayer implements Device {
    powerOn(): void {
        console.log("DVD player is powered on");
    }

    powerOff(): void {
        console.log("DVD player is powered off");
    }

    setVolume(volume: number): void {
        console.log("DVD player does not support volume control");
    }
}

// Abstraction: Remote control
abstract class RemoteControl {
    protected device: Device;

    constructor(device: Device) {
        this.device = device;
    }

    abstract powerOn(): void;
    abstract powerOff(): void;
    abstract setVolume(volume: number): void;
}

// Refined Abstraction: Basic remote control
class BasicRemoteControl extends RemoteControl {
    powerOn(): void {
        this.device.powerOn();
    }

    powerOff(): void {
        this.device.powerOff();
    }

    setVolume(volume: number): void {
        this.device.setVolume(volume);
    }
}

// Refined Abstraction: Advanced remote control with additional features
class AdvancedRemoteControl extends RemoteControl {
    mute(): void {
        this.device.setVolume(0);
        console.log("Volume muted");
    }
}

// Usage
const tv = new TV();
const dvdPlayer = new DVDPlayer();

const basicRemoteForTV = new BasicRemoteControl(tv);
basicRemoteForTV.powerOn();
basicRemoteForTV.setVolume(20);
basicRemoteForTV.powerOff();

const basicRemoteForDVD = new BasicRemoteControl(dvdPlayer);
basicRemoteForDVD.powerOn();
basicRemoteForDVD.setVolume(30);
basicRemoteForDVD.powerOff();

const advancedRemoteForTV = new AdvancedRemoteControl(tv);
advancedRemoteForTV.powerOn();
advancedRemoteForTV.mute();
advancedRemoteForTV.powerOff();

Decorator pattern

In the world of code, a pattern unfolds,
A decorator's tale, as it's often told.
With elegance and flair, it adorns with delight,
A design marvel, gleaming bright.

Imagine a canvas, blank and bare,
Awaiting embellishment, with care.
Enter the decorator, with brushes in hand,
To paint a masterpiece, across the land.

With each stroke, it adds a touch,
Enhancing objects, oh so much.
uA layer of functionality, subtle and fine,
Wrapped in patterns, like a vine.

Like a decorator in a grand old hall,
It dresses up objects, one and all.
But beneath the surface, it retains,
The core essence, where beauty reigns.

So whether it's adding color or spice,
The decorator pattern's advice:
Embellish with grace, but keep in sight,
The essence of objects, shining bright.

In the tapestry of software design,
The decorator pattern, a gem to find.
A touch of class, a stroke of art,
Elevating code, with every part.

// Interface defining the basic functionality
interface Message {
    send(): string;
}

// Concrete component implementing the basic functionality
class SimpleMessage implements Message {
    send(): string {
        return "Simple Message";
    }
}

// Decorator class that adds extra functionality
abstract class MessageDecorator implements Message {
    protected message: Message;

    constructor(message: Message) {
        this.message = message;
    }

    send(): string {
        return this.message.send(); // Delegates message sending to the wrapped object
    }
}

// Concrete decorator adding encryption to the message
class EncryptionDecorator extends MessageDecorator {
    send(): string {
        const originalMessage = this.message.send();
        const encryptedMessage = this.encrypt(originalMessage);
        return `Encrypted Message: ${encryptedMessage}`;
    }

    private encrypt(message: string): string {
        // Just a simple encryption example for demonstration purposes
        return message.split('').reverse().join('');
    }
}

// Concrete decorator adding signature to the message
class SignatureDecorator extends MessageDecorator {
    send(): string {
        const originalMessage = this.message.send();
        const signedMessage = this.sign(originalMessage);
        return `Signed Message: ${signedMessage}`;
    }

    private sign(message: string): string {
        // Just a simple signing example for demonstration purposes
        return message + " [Signed]";
    }
}

// Usage example
let myMessage: Message = new SimpleMessage();
console.log(myMessage.send()); // Output: Simple Message

// Adding encryption to the message
myMessage = new EncryptionDecorator(myMessage);
console.log(myMessage.send()); // Output: Encrypted Message: egasseM elpmiS

// Adding signature to the message
myMessage = new SignatureDecorator(myMessage);
console.log(myMessage.send()); // Output: Signed Message: Encrypted Message: egasseM elpmiS

Facade pattern

In the realm of code, where complexities dwell,
A pattern emerges, weaving its spell.
Its name is Facade, a guardian strong,
Shielding the world from what's complex, and long.

Imagine a maze of tangled threads,
Where confusion reigns, and clarity sheds.
But in the midst, a structure appears,
A facade of simplicity, banishing fears.

Behind its mask, a world is hid,
Of intricate systems, each amid.
Yet to the outside, it presents a face,
A single entry point, a saving grace.

Like a grand gate to a hidden realm,
The facade pattern takes the helm.
It shields the world from chaos deep,
And guides them through with promises to keep.

With elegance and grace, it stands tall,
Simplifying access, for one and all.
Complexity fades, as simplicity reigns,
In the facade's shadow, where order maintains.

So let us hail this pattern divine,
A beacon of clarity in code's design.
For in the facade, we find a guide,
Through the labyrinth of complexity, it will abide.

// Subsystem 1: Lights
class Lights {
    turnOn(): void {
        console.log("Lights are turned on");
    }

    turnOff(): void {
        console.log("Lights are turned off");
    }
}

// Subsystem 2: TV
class TV {
    turnOn(): void {
        console.log("TV is turned on");
    }

    turnOff(): void {
        console.log("TV is turned off");
    }
}

// Subsystem 3: SoundSystem
class SoundSystem {
    turnOn(): void {
        console.log("Sound system is turned on");
    }

    turnOff(): void {
        console.log("Sound system is turned off");
    }
}

// Subsystem 4: SecuritySystem
class SecuritySystem {
    arm(): void {
        console.log("Security system is armed");
    }

    disarm(): void {
        console.log("Security system is disarmed");
    }
}

// Subsystem 5: ClimateControl
class ClimateControl {
    setTemperature(temperature: number): void {
        console.log(`Temperature is set to ${temperature}°C`);
    }

    turnOffAirConditioner(): void {
        console.log("Air conditioner is turned off");
    }

    turnOnHeater(): void {
        console.log("Heater is turned on");
    }
}

// Facade: HomeAutomationFacade
class HomeAutomationFacade {
    private lights: Lights;
    private tv: TV;
    private soundSystem: SoundSystem;
    private securitySystem: SecuritySystem;
    private climateControl: ClimateControl;

    constructor() {
        this.lights = new Lights();
        this.tv = new TV();
        this.soundSystem = new SoundSystem();
        this.securitySystem = new SecuritySystem();
        this.climateControl = new ClimateControl();
    }

    // Method to start the home automation system
    startHome(): void {
        console.log("Starting home automation system");
        this.securitySystem.arm();
        this.lights.turnOn();
        this.tv.turnOn();
        this.soundSystem.turnOn();
        this.climateControl.setTemperature(22);
    }

    // Method to stop the home automation system
    stopHome(): void {
        console.log("Stopping home automation system");
        this.soundSystem.turnOff();
        this.tv.turnOff();
        this.lights.turnOff();
        this.securitySystem.disarm();
        this.climateControl.turnOffAirConditioner();
        this.climateControl.turnOnHeater();
    }
}

// Usage example
const homeAutomationFacade = new HomeAutomationFacade();
homeAutomationFacade.startHome(); // Output: Starting home automation system, Security system is armed, Lights are turned on, TV is turned on, Sound system is turned on, Temperature is set to 22°C
homeAutomationFacade.stopHome(); // Output: Stopping home automation system, Sound system is turned off, TV is turned off, Lights are turned off, Security system is disarmed, Air conditioner is turned off, Heater is turned on

Proxy pattern

In the vast expanse of code's domain,
Where patterns dance and solutions reign,
There dwells a Proxy, noble and true,
A guardian, standing between me and you.

With purpose clear, it takes its stand,
Shielding access with a guiding hand.
A surrogate, it plays its part,
Protecting, controlling, with a gentle heart.

Imagine a door, to secrets unknown,
Where entry's granted, but risks have grown.
Here steps the Proxy, vigilant and wise,
Restricting access, under watchful eyes.

In networking realms, it finds its place,
Caching requests, with effortless grace.
Reducing latency, enhancing speed,
The Proxy serves, fulfilling this need.

In security's embrace, it shines bright,
Filtering requests, with keen foresight.
Guarding sensitive data, from prying eyes,
The Proxy safeguards, as code complies.

But not just in code, its uses expand,
In virtual realms, it lends a hand.
From lazy loading to resource control,
The Proxy pattern plays its role.

So hail the Proxy, in code's grand scheme,
A protector, a guardian, in a digital dream.
With purpose clear and use cases vast,
The Proxy pattern endures, steadfast.

// Interface defining the basic functionality
interface BankAccount {
    deposit(amount: number): void;
    withdraw(amount: number): void;
    getBalance(): number;
}

// Concrete component implementing the basic functionality
class ConcreteBankAccount implements BankAccount {
    private balance: number;

    constructor(initialBalance: number) {
        this.balance = initialBalance;
    }

    deposit(amount: number): void {
        this.balance += amount;
        console.log(`Deposited ${amount} into the account. Current balance: ${this.balance}`);
    }

    withdraw(amount: number): void {
        if (amount <= this.balance) {
            this.balance -= amount;
            console.log(`Withdrawn ${amount} from the account. Current balance: ${this.balance}`);
        } else {
            console.log("Insufficient funds!");
        }
    }

    getBalance(): number {
        return this.balance;
    }
}

// Proxy class that controls access to the ConcreteBankAccount
class BankAccountProxy implements BankAccount {
    private concreteBankAccount: ConcreteBankAccount;
    private isAdmin: boolean;

    constructor(initialBalance: number, isAdmin: boolean = false) {
        this.concreteBankAccount = new ConcreteBankAccount(initialBalance);
        this.isAdmin = isAdmin;
    }

    deposit(amount: number): void {
        this.checkAccess();
        this.concreteBankAccount.deposit(amount);
    }

    withdraw(amount: number): void {
        this.checkAccess();
        this.concreteBankAccount.withdraw(amount);
    }

    getBalance(): number {
        return this.concreteBankAccount.getBalance();
    }

    private checkAccess(): void {
        if (!this.isAdmin) {
            console.log("Access denied. You are not authorized to perform this action.");
            throw new Error("Access denied");
        }
    }
}

// Usage example
const bankAccountAdmin: BankAccount = new BankAccountProxy(1000, true); // Admin account
const bankAccountUser: BankAccount = new BankAccountProxy(500); // Regular user account

// Admin can perform all actions
bankAccountAdmin.deposit(500); // Output: Deposited 500 into the account. Current balance: 1500
bankAccountAdmin.withdraw(200); // Output: Withdrawn 200 from the account. Current balance: 1300
console.log("Balance:", bankAccountAdmin.getBalance()); // Output: Balance: 1300

// Regular user can only view balance
console.log("Balance:", bankAccountUser.getBalance()); // Output: Balance: 500
bankAccountUser.deposit(200); // Output: Access denied. You are not authorized to perform this action.
bankAccountUser.withdraw(100); // Output: Access denied. You are not authorized to perform this action.

Composite pattern

In the forest of code, where structures abound,
There blooms a pattern, both simple and profound.
Its name is Composite, a tapestry grand,
Uniting objects, across the land.

With purpose clear, it takes its stand,
To compose hierarchies, with a guiding hand.
A tree of nodes, with branches wide,
A structure flexible, where entities reside.

Imagine a tree, with roots so deep,
Where each node holds, a secret to keep.
But in this realm, there's more to see,
As nodes unite, in harmony.

The Composite, it joins objects diverse,
In a single structure, they converse.
From leaves to branches, to the root they bind,
A cohesive whole, of a different kind.

In GUI realms, it finds its place,
As widgets gather, with seamless grace.
Buttons and panels, in a hierarchy tall,
The Composite pattern unites them all.

In file systems, it reigns supreme,
As directories nest, in a recursive dream.
Files and folders, in a tree they dwell,
The Composite pattern, weaves its spell.

So hail the Composite, in code's grand scheme,
A structure versatile, like a timeless stream.
With purpose clear and use cases vast,
The Composite pattern endures, steadfast.

// Component interface
interface FileSystemComponent {
    getName(): string;
    getSize(): number;
}

// Leaf class representing a file
class File implements FileSystemComponent {
    private name: string;
    private size: number;

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

    getName(): string {
        return this.name;
    }

    getSize(): number {
        return this.size;
    }
}

// Composite class representing a directory
class Directory implements FileSystemComponent {
    private name: string;
    private components: FileSystemComponent[];

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

    add(component: FileSystemComponent): void {
        this.components.push(component);
    }

    remove(component: FileSystemComponent): void {
        const index = this.components.indexOf(component);
        if (index !== -1) {
            this.components.splice(index, 1);
        }
    }

    getName(): string {
        return this.name;
    }

    getSize(): number {
        let totalSize = 0;
        this.components.forEach(component => {
            totalSize += component.getSize();
        });
        return totalSize;
    }
}

// Usage example
const file1 = new File("document1.txt", 100); // File with size 100 bytes
const file2 = new File("document2.txt", 200); // File with size 200 bytes
const file3 = new File("image.jpg", 500);     // File with size 500 bytes

const directory1 = new Directory("Documents");
directory1.add(file1);
directory1.add(file2);

const directory2 = new Directory("Pictures");
directory2.add(file3);

const rootDirectory = new Directory("Root");
rootDirectory.add(directory1);
rootDirectory.add(directory2);

// Calculate size of the entire file system
console.log("Total size of the file system:", rootDirectory.getSize()); // Output: Total size of the file system: 800

Flywieght pattern or Pool pattern

In the realm of software, where memory does dwell,
A pattern arises, with a story to tell.
Its name is Flyweight, a design so light,
A guardian of memory, shining bright.

With purpose clear, it takes its place,
To manage resources with elegance and grace.
A pool of objects, it seeks to share,
Reducing overhead, with a mindful care.

Imagine a garden, with flowers so fair,
Each petal unique, in the fragrant air.
But in this garden, there lies a scheme,
Where petals unite, like a seamless dream.

The Flyweight, it stores common traits,
Intrinsic properties, it deftly waits.
Extrinsic details, it shares among,
To conserve memory, like a gentle song.

In graphical realms, it finds its role,
With sprites and textures, it takes control.
Reusing objects, with colors and shapes,
The Flyweight pattern, its purpose drapes.

In text processing, it lends its hand,
With characters and fonts, across the land.
Caching glyphs, with glyphs so slight,
The Flyweight pattern, brings delight.

So hail the Flyweight, in code's grand quest,
A keeper of memory, at its best.
With purpose clear and use cases vast,
The Flyweight pattern endures, steadfast.

// Flyweight interface
interface Enemy {
    attack(): void;
}

// Concrete flyweight class representing an enemy
class ConcreteEnemy implements Enemy {
    private type: string;
    private strength: number;
    private specialAbility: string;

    constructor(type: string, strength: number, specialAbility: string) {
        this.type = type;
        this.strength = strength;
        this.specialAbility = specialAbility;
    }

    attack(): void {
        console.log(`${this.type} enemy attacks with strength ${this.strength} and uses special ability: ${this.specialAbility}`);
    }
}

// Flyweight factory class
class EnemyFactory {
    private enemies: { [key: string]: ConcreteEnemy } = {};

    getEnemy(type: string, strength: number, specialAbility: string): ConcreteEnemy {
        const key = `${type}-${strength}`;
        if (!this.enemies[key]) {
            this.enemies[key] = new ConcreteEnemy(type, strength, specialAbility);
        }
        return this.enemies[key];
    }
}

// Client code (game simulation)
const factory = new EnemyFactory();

// Simulate spawning enemies in the game
const enemyTypes = ["Goblin", "Orc", "Skeleton"];
const specialAbilities = ["Fireball", "Stealth", "Summon Minions"];

for (let i = 0; i < 15; i++) {
    const enemyType = enemyTypes[Math.floor(Math.random() * enemyTypes.length)]; // Randomly choose enemy type
    const enemyStrength = Math.floor(Math.random() * 5) + 1; // Randomly choose enemy strength (1 to 5)
    const enemyAbility = specialAbilities[Math.floor(Math.random() * specialAbilities.length)]; // Randomly choose enemy special ability
    const enemy = factory.getEnemy(enemyType, enemyStrength, enemyAbility);
    enemy.attack();
}

Dr Seuss on Polymorphism

michael matos — Sun, 28 Apr 2024 20:20:17 +0000

Polymorphism: plug-n-playability

Polymorphism, it's a plug and play delight,
Where objects morph to fit just right.
Like a versatile plug in a socket's embrace,
In different methods, they find their place.

No need to fret about type or shape,
Polymorphism ensures there's no red tape.
With flexibility and ease, it's always at hand,
In the coding world, where wonders expand.

Kinds of polymorphism

Subtyping polymorphism
Ad-hoc polymorphism or method overloading
Parametric polymorphism or Generics
Row polymorphism or better said: if walks like a duck and quacks like a duck it's duck typing

Subtyping polymorphism

In the whimsical world of coding, there lived a concept quite grand,
Called "inheritance polymorphism" in a far-off coding land.
It's a tale of objects and classes, oh so merry,
Where each bit of code is like a character, quite contrary.

Now, picture a class, a blueprint, you see,
With methods and data, all part of its decree.
But wait! There's a twist, a magical charm,
Inheritance comes along to prevent any harm.

When one class inherits from another, you see,
It gains all the traits, quite effortlessly.
Like a child inheriting traits from their kin,
The new class inherits, it's a wonderful win!

But here's where the tale takes a twist so divine,
Polymorphism enters, oh how it shines!
For you see, a child class can act as its own,
With methods and data, in a world it can roam.

Imagine a Cat, with its meows and its purrs,
Inherits from Animal, with its roars and its stirs.
But when asked to speak, in a language so neat,
The Cat says "Meow," while the Lion, "Roar!" to repeat.

First comes the definition, a blueprint so bright,
With fields and functions, oh what a sight!
But if it inherits, there's more to behold,
As it gains from its parent, stories untold.

Behind the scenes, in a memory land,
Superclasses are initialized, hand in hand.
The constructor is called, to set things aright,
From parent to child, in the soft coding light.

When methods are called, oh what a spree,
The runtime environment searches, from A to Z.
It looks in the subclass, then up it will go,
Through the inheritance chain, to put on a show.

And when it finds the method, a joyous display,
It dispatches and calls it, without delay.
Polymorphism reigns, as objects align,
Inheritance's magic, truly divine.

But don't forget access, to keep things in line,
With public and private, oh so fine.
Encapsulation rules, with a watchful eye,
To protect our code, as it dances in the sky.

So remember the tale, of inheritance grand,
In the land of code, where wonders stand.
With memory, methods, and objects so bright,
Inheritance's story, a true delight!

// Define a base class Vehicle
class Vehicle {
  constructor(public name: string) {}

  drive(): void {
    console.log(`${this.name} is being driven.`);
  }
}

// Define a subclass Car inheriting from Vehicle
class Car extends Vehicle {
  constructor(name: string) {
    super(name);
  }

  // Additional method specific to Car
  honk(): void {
    console.log(`${this.name} is honking.`);
  }
}

// Define another subclass Plane inheriting from Vehicle
class Plane extends Vehicle {
  constructor(name: string) {
    super(name);
  }

  // Additional method specific to Plane
  fly(): void {
    console.log(`${this.name} is flying.`);
  }
}

// Create instances of subclasses and demonstrate inheritance
const myCar = new Car("Toyota");
const myPlane = new Plane("Boeing");

myCar.drive();  // Output: Toyota is being driven.
myCar.honk();   // Output: Toyota is honking.

myPlane.drive(); // Output: Boeing is being driven.
myPlane.fly();   // Output: Boeing is flying.

Ad-hoc polymorphism or method overloading

In the land of coding, oh what a sight,
There's a concept called polymorphism, shining so bright.
But wait, there's a twist, a special kind of charm,
It's ad hoc polymorphism, in the coding farm.

Now, let me tell you a tale, oh so merry,
Of ad hoc polymorphism, oh how it's airy.
Imagine you have a function, simple and neat,
But it can act differently, depending on its seat.

You see, ad hoc polymorphism is quite unique,
It's like a shape-shifting technique.
The same function can do this or that,
Based on the types it's given, imagine that!

One moment it's adding numbers, oh so fine,
The next it's concatenating strings, in a line.
It adapts and adjusts, with such grace,
No need for inheritance, in this coding space.

It's like a wizard with spells, so clever,
Changing its form, and doing it ever.
With typeclasses or overloading, it's quite a show,
Ad hoc polymorphism, stealing the glow.

So in the land of coding, where wonders thrive,
Ad hoc polymorphism, keeps the code alive.
It's flexibility and power, a sight to behold,
In the whimsical world of coding, oh so bold!

now some examples:

I'm going to use scala here as it supports both methods natively.

method overloading:

// Define a class Calculator
class Calculator {
  // Method to add integers
  def add(a: Int, b: Int): Int = a + b

  // Method to concatenate strings
  def add(a: String, b: String): String = a + b
}

// Create an instance of Calculator
val calculator = new Calculator()

// Use method overloading to demonstrate ad hoc polymorphism
val sumOfIntegers = calculator.add(5, 7)
val concatenatedStrings = calculator.add("Hello, ", "world!")

println(s"Sum of integers: $sumOfIntegers")           // Output: Sum of integers: 12
println(s"Concatenated strings: $concatenatedStrings") // Output: Concatenated strings: Hello, world!

using typeclasses:

// Define a type class Addable
trait Addable[T] {
  def add(a: T, b: T): T
}

// Define instances of Addable for Int and String
implicit object AddableInt extends Addable[Int] {
  def add(a: Int, b: Int): Int = a + b
}

implicit object AddableString extends Addable[String] {
  def add(a: String, b: String): String = a + b
}

// Define a function to add values of any type T using the Addable type class
def add[T](a: T, b: T)(implicit addable: Addable[T]): T = addable.add(a, b)

// Use type classes to demonstrate ad hoc polymorphism
val sumOfIntegers = add(5, 7)
val concatenatedStrings = add("Hello, ", "world!")

println(s"Sum of integers: $sumOfIntegers")           // Output: Sum of integers: 12
println(s"Concatenated strings: $concatenatedStrings") // Output: Concatenated strings: Hello, world!

Parametric polymorphism or Generics

In the land of coding, there's a polymorphic twist,
A concept called parametric, that you shouldn't miss.
It's a tale of generics, oh so grand,
Where types are flexible, like grains of sand.

Parametric polymorphism, let me explain,
It's like a magic spell, with a wide domain.
Instead of a specific type, you see,
We use a placeholder, for any degree.

With parametric polymorphism, the function's quite slick,
It works for any type, like a clever trick.
No need to rewrite, for each new type that we find,
One function fits all, it's truly refined.

Imagine a box, that holds treasures untold,
With parametric polymorphism, its secrets unfold.
It can hold numbers, strings, or anything at all,
With a single function call, it answers the call.

So if you seek flexibility, in your coding quest,
Parametric polymorphism, is surely the best.
With generics and types, it opens the door,
To a world of possibilities, forevermore.

in scala:

// Define a generic function that works with any type T
def printElement[T](element: T): Unit = {
  println(element)
}

// Using the generic function with different types
printElement(10)         // Output: 10
printElement("Hello")    // Output: Hello
printElement(3.14)       // Output: 3.14

in typescript:

// Define a generic function that works with any type T
function printElement<T>(element: T): void {
  console.log(element);
}

// Using the generic function with different types
printElement(10);        // Output: 10
printElement("Hello");   // Output: Hello
printElement(3.14);      // Output: 3.14

Row polymorphism or better said: if walks like a duck and quacks like a duck it's duck typing

In the coding realm, there's a type tale to be told,
Of row polymorphism, a story quite bold.
It's a whimsical world where types are in sync,
By the structure they hold, not just what they think.

Imagine two creatures, a person and a pet,
With names and with ages, a pair you won't forget.
Though their labels may differ, their essence is the same,
In the land of row polymorphism, they play the same game.

A person named Alice, with an age quite spry,
And Fluffy the pet, with a sparkle in his eye.
Though one's called "name" and the other "petName",
Their structures align, like a well-played game.

Now enters a function, quite clever and bright,
It prints out their info, with all its might.
It cares not for names, nor the labels they wear,
Only the structure they bear, with a flair.

So Alice and Fluffy, they step up to the plate,
With their different names, yet the function can relate.
For row polymorphism, it's all about fit,
By structure, not name, it's a magical writ.

In this whimsical world, where types dance and rhyme,
Row polymorphism shines, every single time.
So remember this tale, as you code and you craft,
In the land of row polymorphism, it's structure that laughs!

// Define a type representing a person
type Person = {
  name: string;
  age: number;
};

// Define a type representing a pet
type Pet = {
  petName: string;
  petAge: number;
};

// Define a function that accepts any object with a name and age property
function printInfo(obj: { name: string; age: number }): void {
  console.log(`Name: ${obj.name}, Age: ${obj.age}`);
}

// Create objects with different property names but the same structure
const person: Person = { name: "Alice", age: 30 };
const pet: Pet = { petName: "Fluffy", petAge: 5 };

// Both person and pet objects can be passed to the printInfo function
printInfo(person); // Output: Name: Alice, Age: 30
printInfo(pet);    // Output: Name: Fluffy, Age: 5

OOP poetry Part I: Creational patterns

michael matos — Sun, 28 Apr 2024 03:15:02 +0000

A note: while learning new concepts, what has proven the most successful strategy to me is not the meticulous reading of a good article but immerse my eye balls in tons of articles, exposing my mind to different point of views, ways of teaching, different examples and use cases until they finally click. This piece is meant to add to that diversity.

what are creational patterns in OODesign

Creational patterns are a category of design patterns that deal with the process of object creation, providing mechanisms for creating objects in a manner suitable for the situation at hand. These patterns help in abstracting the instantiation process, decoupling the system from the specifics of how objects are created, and promoting flexibility and reusability.

List of patterns

Factory method
Abstract factory
Builder pattern
Prototype pattern
Singleton pattern

Factory method

In software's realm, where logic reigns supreme,
The Factory Method, like a guiding beam,
A pattern woven with meticulous care,
To handle object creation, it's rare.

When classes spawn with varied traits in mind,
The Factory stands as a bridge well-designed.
It crafts the objects, tailored and refined,
As needs arise, its versatility defined.

No longer bound by static instantiation,
It offers freedom, a fluid creation.
Through inheritance's flexible embrace,
New instances emerge in code's embrace.

With Factory Method, complexity tamed,
Creation's process, elegantly framed.
In software's symphony, it takes its part,
A design pattern, a work of art.

abstracting different logistics options:

// Define the Product interface
interface Transport {
    deliver(): string;
}

// Concrete Products
class Truck implements Transport {
    deliver(): string {
        return 'Delivering by Truck';
    }
}

class Ship implements Transport {
    deliver(): string {
        return 'Delivering by Ship';
    }
}

// Creator interface
abstract class LogisticsCompany {
    abstract createTransport(): Transport;

    // Other methods can be here
    shipGoods(): string {
        const transport = this.createTransport();
        return `Goods are ${transport.deliver()}`;
    }
}

// Concrete Creators
class RoadLogistics extends LogisticsCompany {
    createTransport(): Transport {
        return new Truck();
    }
}

class SeaLogistics extends LogisticsCompany {
    createTransport(): Transport {
        return new Ship();
    }
}

// Usage
function clientCode(logistics: LogisticsCompany) {
    console.log(logistics.shipGoods());
}

// Creating Concrete Creators
const roadLogistics = new RoadLogistics();
clientCode(roadLogistics);

const seaLogistics = new SeaLogistics();
clientCode(seaLogistics);

Rationale:
consider using the Factory Method pattern when you need to defer object creation to subclasses or runtime

Creating objects without specifying their concrete classes
Encapsulating object creation logic
Supporting extensibility and flexibility
Decoupling client code from concrete classes

Abstract factory

In software's realm, where structures take flight,
The Abstract Factory, a beacon of light.
A pattern born from creative might,
In code's embrace, it weaves with delight.

With elegance, it crafts a domain wide,
A family of objects, in unity abide.
Abstracting creation, it does confide,
In harmonious design, it takes its stride.

Variants emerge, with subtle grace,
From factories abstract, in their designated space.
Each product unique, yet in common trace,
A symphony of classes, in code's embrace.

In software's tapestry, it finds its place,
The Abstract Factory, a design of grace.

Abstract factory for families of furniture

// Abstract Product A
interface Chair {
    sit(): string;
}

// Concrete Product A1
class ModernChair implements Chair {
    sit(): string {
        return "You are sitting on a modern chair.";
    }
}

// Concrete Product A2
class VictorianChair implements Chair {
    sit(): string {
        return "You are sitting on a victorian chair.";
    }
}

// Abstract Product B
interface Sofa {
    relax(): string;
}

// Concrete Product B1
class ModernSofa implements Sofa {
    relax(): string {
        return "You are relaxing on a modern sofa.";
    }
}

// Concrete Product B2
class VictorianSofa implements Sofa {
    relax(): string {
        return "You are relaxing on a victorian sofa.";
    }
}

// Abstract Factory
interface FurnitureFactory {
    createChair(): Chair;
    createSofa(): Sofa;
}

// Concrete Factory 1
class ModernFurnitureFactory implements FurnitureFactory {
    createChair(): Chair {
        return new ModernChair();
    }

    createSofa(): Sofa {
        return new ModernSofa();
    }
}

// Concrete Factory 2
class VictorianFurnitureFactory implements FurnitureFactory {
    createChair(): Chair {
        return new VictorianChair();
    }

    createSofa(): Sofa {
        return new VictorianSofa();
    }
}

// Client
class Client {
    private chair: Chair;
    private sofa: Sofa;

    constructor(factory: FurnitureFactory) {
        this.chair = factory.createChair();
        this.sofa = factory.createSofa();
    }

    useFurniture(): void {
        console.log(this.chair.sit());
        console.log(this.sofa.relax());
    }
}

// Usage
const modernFactory = new ModernFurnitureFactory();
const victorianFactory = new VictorianFurnitureFactory();

const modernClient = new Client(modernFactory);
modernClient.useFurniture();

const victorianClient = new Client(victorianFactory);
victorianClient.useFurniture();

Rationale:
consider using the Abstract Factory pattern when you need to create families of related objects

Creating families of related objects
Encapsulating object creation logic
Providing a platform-independent interface

Builder pattern

In software's realm, where structures rise,
The Builder Pattern, a grand disguise.
With methodical craft, it shapes the wise,
In code's embrace, its essence lies.

A builder's hand, with precision keen,
Constructs objects from a dream serene.
Step by step, it brings to scene,
A creation tailored, like a serene.

Each step a choice, each choice a thread,
In the fabric of creation, finely bred.
Properties set, with care they're led,
Towards a masterpiece, where they're wed.

Flexibility reigns, in this design's sway,
Variety thrives, in its array.
From simple to complex, day by day,
The Builder Pattern guides the way.

So in software's tapestry, let it adorn,
The Builder Pattern, from dusk to morn.
With its craft, new structures are born,
In the symphony of code, forever sworn.

Builder pattern for building a customizable burger:

// Product
class Burger {
    private size: string;
    private cheese: boolean;
    private lettuce: boolean;
    private tomato: boolean;
    private bacon: boolean;
    private sauce: string;

    constructor(builder: BurgerBuilder) {
        this.size = builder.size;
        this.cheese = builder.cheese;
        this.lettuce = builder.lettuce;
        this.tomato = builder.tomato;
        this.bacon = builder.bacon;
        this.sauce = builder.sauce;
    }

    describe(): string {
        let description = `Size: ${this.size}, Cheese: ${this.cheese ? 'Yes' : 'No'}, Lettuce: ${this.lettuce ? 'Yes' : 'No'}, Tomato: ${this.tomato ? 'Yes' : 'No'}, Bacon: ${this.bacon ? 'Yes' : 'No'}, Sauce: ${this.sauce}`;
        return description;
    }
}

// Builder
class BurgerBuilder {
    size: string;
    cheese: boolean = false;
    lettuce: boolean = false;
    tomato: boolean = false;
    bacon: boolean = false;
    sauce: string = "Ketchup";

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

    addCheese(): BurgerBuilder {
        this.cheese = true;
        return this;
    }

    addLettuce(): BurgerBuilder {
        this.lettuce = true;
        return this;
    }

    addTomato(): BurgerBuilder {
        this.tomato = true;
        return this;
    }

    addBacon(): BurgerBuilder {
        this.bacon = true;
        return this;
    }

    setSauce(sauce: string): BurgerBuilder {
        this.sauce = sauce;
        return this;
    }

    build(): Burger {
        return new Burger(this);
    }
}

// Usage
const burger1 = new BurgerBuilder("Large")
    .addCheese()
    .addLettuce()
    .addTomato()
    .addBacon()
    .setSauce("BBQ")
    .build();

const burger2 = new BurgerBuilder("Medium")
    .addCheese()
    .addTomato()
    .setSauce("Mustard")
    .build();

console.log("Burger 1:", burger1.describe());
console.log("Burger 2:", burger2.describe());

Rationale:
consider using the Builder pattern when you need to simplify complex object creation

Complex object creation
Flexibility and readability
Variability in object construction
Immutability and thread safety
Testability

Prototype pattern

In software's realm, where innovations gleam,
The Prototype Pattern, a visionary dream.
A pattern born from creativity's stream,
In code's embrace, it reigns supreme.

Like a master artist with canvas in hand,
It crafts objects from a fertile land.
Cloning instances, a wondrous command,
A blueprint of creation, finely planned.

With Prototype, new instances bloom,
A replication of a given room.
Efficient and swift, it banishes gloom,
In software's garden, it finds its bloom.

Variations emerge, each with its flair,
From the original, they boldly dare.
Customizations woven with care,
Prototype Pattern, beyond compare.

In the code's symphony, it sings its song,
A design pattern, forever strong.
With its power, new realms belong,
In the world of software, it marches along.

we need an assistant for our example and who's better than dolly the sheep

// Prototype interface
interface Cloneable {
    clone(): Cloneable;
}

// Concrete prototype
class Sheep implements Cloneable {
    private name: string;
    private age: number;
    private color: string;

    constructor(name: string, age: number, color: string) {
        this.name = name;
        this.age = age;
        this.color = color;
    }

    // Clone method to create a deep copy
    clone(): Sheep {
        const clonedSheep = new Sheep(this.name, this.age, this.color);
        return clonedSheep;
    }

    // Method to display sheep details
    display(): string {
        return `Name: ${this.name}, Age: ${this.age}, Color: ${this.color}`;
    }
}

// Client code
const originalSheep = new Sheep("Dolly", 2, "White");
console.log("Original sheep:", originalSheep.display());

// Cloning the original sheep
const clonedSheep1 = originalSheep.clone();
clonedSheep1.display();

// Modifying the cloned sheep
clonedSheep1.color = "Black";
console.log("Cloned sheep 1:", clonedSheep1.display());

// Cloning the original sheep again
const clonedSheep2 = originalSheep.clone();
console.log("Cloned sheep 2:", clonedSheep2.display());

Rationale:
consider using the Prototype pattern when you need to create new objects based on existing ones

Object creation is costly
Variations of objects are needed
Avoiding subclassing
Dynamic runtime changes
Reducing coupling

Singleton pattern

In software's realm, where codes converge,
A Singleton pattern, with its gentle urge.
A solitary instance, it does emerge,
In the symphony of design, it does surge.

Alone it stands, a guardian strong,
Ensuring only one instance, where it belongs.
Threads may dance, and time may prolong,
But Singleton's essence remains lifelong.

In shared resources, its value shines,
A single point of access, in design's confines.
Concurrency tamed, like rhythmic rhymes,
Singleton's presence, in code defines.

With care it's crafted, in classes it dwells,
A unique instance, its story tells.
In software's tapestry, where wisdom swells,
Singleton pattern, its legacy compels.

So in the landscape of software's domain,
Singleton's silhouette shall forever reign.
A solitary guardian, with wisdom to sustain,
In the patterns of design, it shall retain.

class Logger {
    private static instance: Logger | null = null;
    private logs: string[] = [];

    // Private constructor to prevent instantiation from outside
    private constructor() {}

    // Static method to get the singleton instance
    public static getInstance(): Logger {
        if (!Logger.instance) {
            Logger.instance = new Logger();
        }
        return Logger.instance;
    }

    // Method to add a log message
    public log(message: string): void {
        this.logs.push(message);
    }

    // Method to display all log messages
    public displayLogs(): void {
        console.log("===== Log Messages =====");
        this.logs.forEach((log, index) => {
            console.log(`[${index + 1}] ${log}`);
        });
        console.log("========================");
    }
}

// Usage
const logger1 = Logger.getInstance();
logger1.log("Error: File not found.");

const logger2 = Logger.getInstance();
logger2.log("Warning: Database connection lost.");

 // Check if both instances are the same 
 console.log(logger1 === logger2); // Output: true

// Display all log messages
logger1.displayLogs();

Rationale:

consider using the Singleton pattern when you need to ensure there is only one instance of a class in your application

Global access point
Resource management
State management
Performance optimization
Immutable objects

For more examples please visit refactoring.guru

DEV Community: michael matos

Applicatives in typescript

Table of contents

Functors recap

Applicatives

Multiple arguments

Sequential or parallel effectful computation composition

Practical examples

Mappables in typescript

Table of contents

Functors == mappable

Are there other functors, Maybe

Trees can be mappables

So graphs too

Benefits of using functors in your code

Algebraic structures in FP

Table of contents

what do we mean by algebraic structure

Laws

Reasoning for laws

Relationship between structures

Groups are everywhere

FIN

typelevel typescript: a practical view

Table of contents

Benefits of typelevel computation:

Some use cases

Validation, verification and contracts

DSLs and embedded languages:

Configuration and Settings

All that glitters is not gold: typelevel drawbacks

Who is the perfect audience for typelevel computation

Typelevel Typescript: A cheat sheet

Table of contents

Basic Types

Type Aliases

Interfaces

Unions and Intersections

Type Guards

Generics

Mapped Types

Conditional Types

Recursive Types

Index Types

Type Assertions

Template Literal Types

Discriminated Unions

Type Queries

Phantom Types

Example: typelevel addition

OOP poetry part III - behavioural patterns

what are behavioural patterns in OODesign

List of patterns

Chain of responsability

Command pattern

Iterator pattern

Mediator pattern

memento pattern

Oberserver pattern

State pattern

strategy pattern

template method pattern

Visitor pattern

OOP poetry Part II: structural patterns

what are structural patterns in OODesign

List of patterns

Adapter pattern

Bridge pattern

Decorator pattern

Facade pattern

Proxy pattern

Composite pattern

Flywieght pattern or Pool pattern

Dr Seuss on Polymorphism

Polymorphism: plug-n-playability

Kinds of polymorphism

Subtyping polymorphism

Ad-hoc polymorphism or method overloading

Parametric polymorphism or Generics

Row polymorphism or better said: if walks like a duck and quacks like a duck it's duck typing