SOLID Principles Meet Functional Programming

Introduction

SOLID principles are a cornerstone of object-oriented design. They help us build software that’s easier to understand, maintain, and extend. But what happens when we try to apply these ideas to functional programming? It’s not a direct mapping, and honestly, some of them don’t translate perfectly. However, thinking about the spirit behind SOLID can still lead to better functional code. Let’s break it down.

Single Responsibility Principle (SRP)

In OOP, SRP means a class should have only one reason to change. In functional programming, this translates pretty naturally to functions. A good functional unit of work should do one thing and do it well. This means avoiding functions that try to do too much, like fetching data, transforming it, and then rendering it.

Instead of this:

1
function processUserData(userId) {
2
  // Fetch user data
3
  const userData = fetchUser(userId);
4
  // Transform data for display
5
  const displayData = transformForDisplay(userData);
6
  // Render to DOM
7
  renderUser(displayData);
8
}

We aim for something like this:

1
function getUserData(userId) {
2
  // Returns Promise<UserData>
3
}
4

5
function transformUserDataForDisplay(userData) {
6
  // Returns DisplayData
7
}
8

9
function renderUser(displayData) {
10
  // Side effect: renders to DOM
11
}
12

13
// Composed function
14
const processAndRenderUser = async (userId) => {
15
  const userData = await getUserData(userId);
16
  const displayData = transformUserDataForDisplay(userData);
17
  renderUser(displayData);
18
};

Each function has a clear, single responsibility. The composition handles the orchestration.

Open/Closed Principle (OCP)

OCP states that software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. This is tricky in functional programming because immutability and pure functions are key. Modifying a function directly often feels like a violation. The functional way to achieve extensibility is often through composition and higher-order functions.

Instead of modifying an existing function to add new behavior, we can create new functions and compose them with the old ones, or pass functions as arguments.

Consider a filtering function:

1
function filterList(list, predicate) {
2
  return list.filter(predicate);
3
}
4

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

7
const evens = filterList(numbers, n => n % 2 === 0);
8
const greaterThan3 = filterList(numbers, n => n > 3);

We didn’t modify filterList to add new filtering logic. We extended its capability by providing different predicate functions. The original function is ‘closed’ - we don’t change its internals. The behavior is ‘open’ to new possibilities via new predicates.

Liskov Substitution Principle (LSP)

LSP says that objects of a superclass should be replaceable with objects of its subclasses without altering the correctness of the program. In functional programming, where we don’t have traditional inheritance, LSP relates more to function signatures and expected return types. If a function expects a certain type of input (e.g., a number for a sort function), anything that behaves like a number should be acceptable. This is closely tied to polymorphism, which is achieved in FP through generic functions and type classes (or similar concepts in languages like Haskell or Scala).

For example, if you have a function that sums a list of numbers, it should also work with a list of BigInts if they are compatible in terms of the + operation.

Interface Segregation Principle (ISP)

ISP suggests that clients should not be forced to depend on methods they do not use. In functional programming, this means functions should only take the arguments they actually need. Avoid creating large, monolithic functions that require many unrelated parameters. Breaking down large functions into smaller, focused ones naturally adheres to ISP.

Instead of:

1
function processOrder(order, customerInfo, paymentDetails, shippingInfo, inventoryStatus) {
2
  // ... lots of logic using all parameters
3
}

Break it down:

1
function getCustomerData(customerId) { /* ... */ }
2
function getPaymentStatus(orderId) { /* ... */ }
3
function checkInventory(items) { /* ... */ }
4

5
function processOrder(order) {
6
  const customer = getCustomerData(order.customerId);
7
  const payment = getPaymentStatus(order.orderId);
8
  const stockAvailable = checkInventory(order.items);
9

10
  if (payment.isPaid && stockAvailable) {
11
    // proceed with shipping logic...
12
  }
13
}

Each function depends only on the data it needs.

Dependency Inversion Principle (DIP)

DIP states that high-level modules should not depend on low-level modules. Both should depend on abstractions. In functional programming, abstractions often come in the form of function arguments or higher-order functions. Dependencies are often injected via function parameters.

Say you have a service that needs to log messages. Instead of hardcoding a specific logger, you pass a logger function as an argument:

1
function createReport(data, logger) {
2
  logger.log('Starting report generation.');
3
  const report = generateReportContent(data);
4
  logger.log('Report generated.');
5
  return report;
6
}
7

8
// Example usage with a console logger
9
createReport(myData, console);
10

11
// Example usage with a file logger (hypothetical)
12
// createReport(myData, fileLogger);

The createReport function (high-level) depends on the logger abstraction (a function with a log method), not a concrete logging implementation. This makes it easy to swap out logging mechanisms.

Conclusion

While SOLID wasn’t designed with functional programming in mind, its core ideas are surprisingly relevant. Focusing on single responsibilities, extensibility through composition, clear interfaces, and dependency injection via arguments leads to cleaner, more maintainable functional code. It’s about understanding the principles and adapting them to the paradigm, not forcing a one-to-one translation.

Tags: Functional Programming, SOLID Principles, Software Design, Clean Code, Programming Concepts