DEV Community: Flavio Rosselli

SOLID Principles in Functional Programming (FP) with examples

Flavio Rosselli — Fri, 04 Oct 2024 18:09:15 +0000

The SOLID principles are five design principles that aim to create software easy-to-maintain, flexible, and scalable. They were introduced by Robert C. Martin (Uncle Bob) and are widely adopted in software development.

While the SOLID principles are traditionally applied to Object-Oriented Programming (OOP), they can also be adapted to Functional Programming (FP). Here's an overview of each SOLID principle with real-world examples in Typescript using functional programming concepts.

1. Single Responsibility Principle (SRP)

A function should have one, and only one, reason to change. It should do one thing (responsibility) and do it well.

In FP, functions should focus on solving a single problem or performing one task. By adhering to SRP, you can easily reason about code, test it, and change individual behaviours without affecting other parts of the system.

When to use: Whenever you need to ensure modularity and separation of concerns. It’s easier to maintain, test, and refactor.

When to refactor:

When a function has multiple unrelated responsibilities.
When a function is becoming too large and complex.
When a function is difficult to understand or test.

Example: Let’s say we have an app that handles user registration, validation, and email sending. Each function should focus on one task:

const validateEmail = (email: string): boolean => /^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(email);

const sendEmail = (email: string, content: string): void => {/* logic to send email */};

const registerUser = (email: string, password: string): void => {
  if (!validateEmail(email)) throw new Error('Invalid email');
  // logic to register user
  sendEmail(email, 'Welcome to the platform!');
};

2. Open/Closed Principle (OCP)

Software entities (functions, modules, etc.) should be open for extension but closed for modification. This means you can add new functionality without changing existing code.

You should build functions in a way that new behavior can be added without changing existing code. In FP, higher-order functions and function composition can help achieve this.

When to use: When you want to add new features (e.g., different notification methods) without modifying the core logic.

When to refactor:

When you need to add new functionality to an existing system without modifying the existing code.
When you want to make your code more extensible and maintainable.

Example: Suppose we want to extend our user registration system to support different types of notifications (email, SMS).

type Notify = (message: string) => void;

const emailNotify: Notify = (message) => {/* send email logic */ };
const smsNotify: Notify = (message) => {/* send SMS logic */ };

const registerUser = (email: string, password: string, notify: Notify): void => {
  if (!validateEmail(email)) throw new Error('Invalid email');
  // logic to register user
  notify('Welcome to the platform!');
};

// extend functionality without modifying registerUser
registerUser('user@example.com', 'password123', emailNotify);
registerUser('user@example.com', 'password123', smsNotify);

3. Liskov Substitution Principle (LSP)

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of the program.

In FP, this translates to ensuring that different implementations of a function or data transformation behave consistently. If you replace one function with another that has the same signature, the program should work as expected.

When to use (or refactor): When you need interchangeable behaviors or formatters. It helps keep your code flexible and open to new use cases.

Example: Let’s assume we have a function that formats user data for export in different formats (JSON, CSV).

type Formatter = (data: any) => string;

const jsonFormatter: Formatter = (data) => JSON.stringify(data);
const csvFormatter: Formatter = (data) => {
  // logic to convert data to CSV
  return "CSV format";
};

const exportUserData = (data: any, formatter: Formatter): string => formatter(data);

console.log(exportUserData({ name: 'John Doe' }, jsonFormatter)); // JSON output
console.log(exportUserData({ name: 'John Doe' }, csvFormatter)); // CSV output

4. Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use. Instead of one large interface, multiple smaller interfaces are preferred.

This principle suggests that functions should only accept the parameters they need. In FP, this can be thought of as creating smaller, more specific functions rather than large ones that do too much or rely on too many inputs.

When to use: When you want to avoid functions taking large input structures or unnecessary dependencies.

When to refactor:

When you have a large interface that is used by multiple clients.
When you want to create more reusable and modular components.

Example:
Creating smaller, focused functions instead of large interfaces allows clients to only depend on what they need.

const sendMessage = (message: string): void => {
    // Logic to send message
    console.log(`Message sent: ${message}`);
};

const receiveMessage = (): string => {
    // Logic to receive message
    const message = "Hello!";
    console.log(`Message received: ${message}`);
    return message;
};

// each function serves a specific purpose without unnecessary dependencies.

5. Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions.

In FP, this can be applied by having high-level functions depend on abstractions (like higher-order functions) rather than concrete implementations. We decouple the implementation of a function from its usage by passing behaviour as a function.

When to use: When you want to keep your code loosely coupled, allowing easy swapping of different behaviours without changing the high-level logic, enhancing flexibility and testability.

When to refactor:

When you want to decouple high-level modules from low-level modules.
When you want to make your code more flexible and testable.

Example: Using higher-order functions to inject dependencies allows us to decouple high-level logic from low-level implementations.

interface NotificationSender {
    send(message: string): void;
}

const notifyUser = (notificationSender: NotificationSender, message: string): void => notificationSender.send(message);

// Low-level module implementation
const emailSender: NotificationSender = {
    send(message) { console.log(`Email sent with message: ${message}`) }
};

// High-level module using dependency injection
notifyUser(emailSender, "Notification sent!");

Example: Suppose we want a notification system that can support multiple notification methods (email, SMS, etc.) but without hardcoding them.

type Notify = (message: string) => void;

const notifyUser = (message: string, notify: Notify): void => notify(message);

const emailNotify: Notify = (message) => {/* send email logic */ };
const smsNotify: Notify = (message) => {/* send SMS logic */ };

// High-level notifyUser depends on the abstraction (Notify), not the concrete implementation
notifyUser('Welcome!', emailNotify);
notifyUser('Your order is confirmed!', smsNotify);

Key Points:

SRP: Each function has a single, well-defined responsibility.
OCP: New functionality can be added by creating new functions without modifying existing ones.
LSP: Functions that take interfaces as arguments can be used with any implementation of those interfaces.
ISP: Functions are designed with small, focused interfaces.
DIP: Functions depend on abstractions (interfaces) rather than concrete implementations.

Functional Programming (FP) Principles with examples

Flavio Rosselli — Thu, 03 Oct 2024 16:26:46 +0000

Functional programming (FP) is a programming paradigm that emphasizes the use of functions to create software. Unlike imperative programming, which focuses on performing tasks through structured sequences of statements, functional programming is declarative, meaning it describes what the program should accomplish without detailing how to achieve it.

This approach leads to code that is often cleaner, more predictable, easier to test, and less prone to bugs, avoiding changing-state and mutable data.

Key Principles of Functional Programming

1. Immutability
Data is immutable in FP, meaning it cannot be changed once created. If changes are needed, new data structures are created. This helps prevent side effects and makes code easier to reason about.

map is a good example of immutability. It creates a new array without modifying (mutating) the original one.

const originalArray = [1, 2, 3];
const newArray = [...originalArray, 4]; // originalArray remains unchanged

// map example
const numbers = [1, 2, 3];
const doubledNumbers = numbers.map(n => n * 2);

console.log(numbers); // [1, 2, 3], original array is unchanged
console.log(doubledNumbers); // [2, 4, 6], new array created

2. Pure Functions
A pure function always produces the same output for the same input and has no side effects. This means it doesn't modify any external state.

const add = (a: number, b: number): number => a + b;

console.log(add(2, 3)); // 5, always returns the same value for given inputs

3. First-Class Citizens
Functions are treated as "first-class citizens", meaning they can be passed as arguments, returned from other functions, or assigned to variables.

const multiply = (x: number) => (y: number): number => x * y;
const double = multiply(2);

console.log(double(5)); // 10

4. Higher-Order Functions
A higher-order function takes one or more functions as arguments or returns a function. This enables powerful abstractions and code reuse.

map, filter, reduce, and sort are higher-order functions.

const applyOperation = (x: number, y: number, operation: (a: number, b: number) => number): number => operation(x, y);

const multiply = (a: number, b: number) => a * b;
console.log(applyOperation(4, 5, multiply)); // 20

// map, filter and reduce examples 
const numbers: number[] = [1, 2, 3, 4];
const doubled: number[] = numbers.map((n) => n * 2);
const evens: number[] = numbers.filter((n) => n % 2 === 0);
const sum: number = numbers.reduce((accumulator, current) => accumulator + current, 0);

console.log(doubled); // [2, 4, 6, 8]
console.log(evens);   // [2, 4]
console.log(sum);     // 10

Extra

Recursion and Function Composition are not a FP principle, but they walk together with it.

1. Recursion
Recursion is a function that calls itself with smaller inputs until it reaches a condition (base case). Functional programming often uses recursion to solve problems instead of loops.

const sumArray = (arr: number[], index: number = 0): number => {
    if (index === arr.length) return 0;
    return arr[index] + sumArray(arr, index + 1);
}

const numbers = [1, 2, 3, 4, 5];
const totalSum = sumArray(numbers);
console.log(totalSum); // 15

2. Function Composition
Combining simple functions to build more complex functions. This allows for more modular, reusable code.

const toUpperCase = (str: string): string => str.toUpperCase();
const exclaim = (str: string): string => `${str}!`;

// composition
const shout = (str: string) => exclaim(toUpperCase(str));

console.log(shout("hello")); // "HELLO!"

Everything you need to know about UUID.

Flavio Rosselli — Wed, 02 Oct 2024 12:36:10 +0000

A Universally Unique Identifier (UUID) is a 128-bit label used in computer systems to identify information uniquely. UUIDs are designed to be unique across space and time, allowing them to be generated independently without a central authority, minimising the risk of duplication.

UUIDs serve various purposes, including:

Identifying records in databases.
Tagging objects in distributed systems.
Serving as primary keys in applications where uniqueness is critical.

Real-world Use Cases

Databases: UUID is used as the primary key in relational databases to ensure the unique identification of records.
Microservices: Facilitate service communication by providing unique identifiers for requests and resources.
IoT Devices: Identify devices uniquely in a network, ensuring that data from multiple sources can be aggregated without conflicts.

Advantages and Disadvantages in use of UUID

Advantages:

Global Uniqueness: UUIDs are extremely unlikely to collide, making them suitable for distributed systems where multiple nodes generate identifiers independently.
No Central Authority Required: They can be generated without coordination, which simplifies operations in distributed environments.
Scalability: They work well in systems that require scaling across multiple servers or services.

Disadvantages:

Storage Size: UUIDs consume more space (128 bits) compared to traditional integer IDs (typically 32 bits), which can lead to increased storage costs.
Performance Issues: Indexing UUIDs can degrade database performance due to their randomness and size, leading to slower query times compared to sequential IDs.
User Unfriendliness: UUIDs are not easily memorable or user-friendly when presented in user interfaces.

The Standard

The standard representation of a UUID consists of 32 hexadecimal characters divided into five groups, separated by hyphens, following the format 8-4-4-4-12, resulting in a total of 36 characters (32 alphanumeric plus 4 hyphens).

The UUID format can be visualized as follows:

xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Where:

M indicates the UUID version.
N indicates the variant, which helps interpret the UUID's layout.

Components of a UUID

TimeLow: 4 bytes (8 hex characters) representing the low field of the timestamp.
TimeMid: 2 bytes (4 hex characters) representing the middle field of the timestamp.
TimeHighAndVersion: 2 bytes (4 hex characters) that include the version number and the high field of the timestamp.
ClockSequence: 2 bytes (4 hex characters) used to help avoid collisions, especially when multiple UUIDs are generated in quick succession or if the system clock is adjusted.
Node: 6 bytes (12 hex characters), typically representing the MAC address of the generating node.

Types of UUIDs

Version 1: Time-based UUIDs that use a combination of the current timestamp and the MAC address of the generating node. This version ensures uniqueness across space and time.
Version 2: Similar to version 1 but includes local domain identifiers; however, it is less commonly used due to its limitations.
Version 3: Name-based UUIDs generated using an MD5 hash of a namespace identifier and a name.
Version 4: Randomly generated UUIDs that provide high randomness and uniqueness, with only a few bits reserved for versioning.
Version 5: Like version 3 but uses SHA-1 for hashing, making it more secure than version 3.

Variants

The variant field in a UUID determines its layout and interpretation. The most common variants include:

Variant 0: Reserved for NCS backward compatibility.
Variant 1: The standard layout used for most UUIDs.
Variant 2: Used for DCE Security UUIDs, which are less common.
Variant 3: Reserved for future definitions.

Example

For Version 4, a UUID might look like this:

550e8400-e29b-41d4-a716-446655440000

Here:

41d4 indicates it's a version 4.
a7 represents the variant, in this case, the common "Leach-Salz" variant.

How UUIDs are Calculated

Version 1 (Time-based):
- The timestamp is typically the number of 100-nanosecond intervals since October 15, 1582 (the date of the Gregorian calendar reform).
- The node is the MAC address of the machine generating the UUID.
- The clock sequence helps ensure uniqueness when the clock time changes (e.g., due to system restarts).
Version 3 and Version 5 (Name-based):
- A namespace (like a DNS domain) is combined with a name (like a file path or URL) and hashed.
- The hash (MD5 for version 3, SHA-1 for version 5) is then structured into a UUID format, ensuring the version and variant fields are properly set.
Version 4 (Random-based):
- Random or pseudo-random numbers are generated for the 122 bits of the UUID.
- The version and variant fields are set accordingly, ensuring compliance with UUID standards.

UUIDv4 Calculation Example

Step 1: Generate 128 Random Bits

Let's assume we generate the following 128-bit random value:

11001100110101101101010101111010101110110110111001011101010110110101111011010011011110100100101111001011

Step 2: Apply UUIDv4 Version and Variant

Version: Replace bits 12-15 (4th character) with 0100 (for UUID version 4).
Original: 1100 becomes 0100 → Updated value in this position.
Variant: Replace bits 6-7 of the 9th byte with 10 (for the RFC 4122 variant).
Original: 11 becomes 10 → Updated value in this position.

Step 3: Format into Hexadecimal

Convert the 128-bit binary into 5 hexadecimal groups:

32-bit group: 11001100110101101101010101111010 → ccda55ba
16-bit group: 1011101101101110 → b76e
16-bit group: 0100010101000101 → 4545 (with 0100 for version 4)
16-bit group: 1010110111110010 → adf2 (with 10 for the variant)
48-bit group: 11010011011110100100101111001011 → d39d25cb

Step 4: Combine the Groups

The final UUID would look like this:
ccda55ba-b76e-4545-adf2-d39d25cb