SOLID Principles in TypeScript: Functional vs Object-Oriented Approaches

I recently came across an article on SOLID principles at Daily Dev. While I found the approach interesting, one comment particularly caught my attention:

JavaScript is not an object-oriented language, it's a functional language that happens to support the class keyword and has objects. I'd hate for someone to read this and think they're supposed to be writing classes as their first thought – we should really be writing functions primarily.

This perspective resonated with me. Rather than simply accepting one paradigm over another, I decided to refactor the examples and explore both approaches side by side. In this article, I present a comparative analysis of SOLID principles implemented in both object-oriented and functional TypeScript, examining the strengths and trade-offs of each approach for Node.js developers.

📝 Introduction

The SOLID principles provide a foundation for writing maintainable, flexible code regardless of programming paradigm. This article examines how these principles can be applied in both functional and object-oriented TypeScript, comparing their implementations, advantages, and best use cases. By understanding both approaches, you can make informed decisions about which paradigm better suits different aspects of your Node.js applications.

🧱 What Does SOLID Stand For?

S — Single Responsibility Principle (SRP)
O — Open/Closed Principle (OCP)
L — Liskov Substitution Principle (LSP)
I — Interface Segregation Principle (ISP)
D — Dependency Inversion Principle (DIP)

Let's explore each principle with both functional and object-oriented TypeScript approaches.

✅ 1. Single Responsibility Principle (SRP)

A module, class, or function should have only one reason to change.

❌ Wrong Approach

function processUserRegistration(userData) {
  // 1. Validate input
  if (!userData.email.includes('@')) {
    throw new Error('Invalid email');
  }

  // 2. Save user to DB (simulated)
  const userId = Math.floor(Math.random() * 1000);

  // 3. Send welcome email (simulated)
  console.log(`Sending welcome email to ${userData.email}`);

  return userId;
}

Why this is wrong:

This function is doing too many things at once - validating data, saving to a database, and sending emails
Each of these responsibilities could change for different reasons (validation rules change, database structure changes, email content changes)
It's difficult to test each part independently
Changes to any one responsibility require modifying the entire function, increasing the risk of bugs

✅ Functional TypeScript Approach

// Define types
type User = {
  email: string;
  name?: string;
};

// Pure functions with single responsibilities
const validateUser = (user: User): boolean => 
  user.email.includes('@');

const saveUserToDatabase = (user: User): number => {
  const userId = Math.floor(Math.random() * 1000);
  console.log(`User saved with ID ${userId}`);
  return userId;
};

const sendWelcomeEmail = (email: string): void => {
  console.log(`Sending welcome email to ${email}`);
};

// Composition of functions
const registerUser = (user: User): number => {
  if (!validateUser(user)) {
    throw new Error('Invalid email');
  }
  
  const userId = saveUserToDatabase(user);
  sendWelcomeEmail(user.email);
  return userId;
};

// Usage
const user: User = { email: 'alice@example.com' };
const userId = registerUser(user);
console.log(`New user ID: ${userId}`);

✅ Well-Designed OOP TypeScript Approach

// Define types
interface User {
  email: string;
  name?: string;
}

// Single responsibility classes
class UserValidator {
  public validate(user: User): boolean {
    return user.email.includes('@');
  }
}

class UserRepository {
  public save(user: User): number {
    const userId = Math.floor(Math.random() * 1000);
    console.log(`User saved with ID ${userId}`);
    return userId;
  }
}

class EmailService {
  public sendWelcomeEmail(email: string): void {
    console.log(`Sending welcome email to ${email}`);
  }
}

// Service that coordinates these responsibilities
class UserRegistrationService {
  private validator: UserValidator;
  private repository: UserRepository;
  private emailService: EmailService;

  constructor(
    validator: UserValidator,
    repository: UserRepository,
    emailService: EmailService
  ) {
    this.validator = validator;
    this.repository = repository;
    this.emailService = emailService;
  }

  public registerUser(user: User): number {
    if (!this.validator.validate(user)) {
      throw new Error('Invalid email');
    }
    
    const userId = this.repository.save(user);
    this.emailService.sendWelcomeEmail(user.email);
    return userId;
  }
}

// Usage
const registrationService = new UserRegistrationService(
  new UserValidator(),
  new UserRepository(),
  new EmailService()
);

const user: User = { email: 'alice@example.com' };
const userId = registrationService.registerUser(user);
console.log(`New user ID: ${userId}`);

🔄 FP vs OOP Evaluation for SRP

FP Advantages:

More concise with less boilerplate code
Pure functions are inherently testable in isolation
Data flow is more explicit and easier to trace
No need to manage object state or worry about mutation

OOP Advantages:

Clear encapsulation of related behaviors within classes
Explicit interfaces make the contract clearer
Can manage internal state when needed (e.g., database connections)
Familiar structure for enterprise developers

Better for Node.js context:

FP is often better for HTTP handlers/controllers - These typically transform inputs to outputs with minimal state
OOP is often better for services with shared resources - Like database connections or external API clients

✅ 2. Open/Closed Principle (OCP)

Software entities should be open for extension but closed for modification.

❌ Wrong Approach

function getDiscountedPrice(customerType, price) {
  if (customerType === 'regular') {
    return price * 0.9;
  } else if (customerType === 'vip') {
    return price * 0.8;
  } else if (customerType === 'platinum') {
    return price * 0.7;
  } else {
    return price;
  }
}

Why this is wrong:

Every time you need to add a new customer type, you must modify the existing function
This modification risks introducing bugs in existing, working code
The function becomes longer and more complex with each new type
It's difficult to test each discount case in isolation
The code violates the Open/Closed Principle because it's not closed for modification

✅ Functional TypeScript Approach

// Define types
type DiscountFn = (price: number) => number;

// Strategy map using functions
const discountStrategies: Record = {
  regular: (price: number) => price * 0.9,
  vip: (price: number) => price * 0.8,
  platinum: (price: number) => price * 0.7,
  default: (price: number) => price
};

// Function to get the appropriate discount strategy
const getDiscountStrategy = (customerType: string): DiscountFn => 
  discountStrategies[customerType] || discountStrategies.default;

// Apply discount function
const getDiscountedPrice = (customerType: string, price: number): number => 
  getDiscountStrategy(customerType)(price);

// To extend, just add new strategies without modifying existing code
discountStrategies.gold = (price: number) => price * 0.75;

// Usage
console.log(getDiscountedPrice('vip', 100)); // 80
console.log(getDiscountedPrice('gold', 100)); // 75

✅ Well-Designed OOP TypeScript Approach

// Define the interface for discount strategies
interface DiscountStrategy {
  calculateDiscount(price: number): number;
}

// Concrete strategy implementations
class RegularCustomerDiscount implements DiscountStrategy {
  calculateDiscount(price: number): number {
    return price * 0.9;
  }
}

class VIPCustomerDiscount implements DiscountStrategy {
  calculateDiscount(price: number): number {
    return price * 0.8;
  }
}

class PlatinumCustomerDiscount implements DiscountStrategy {
  calculateDiscount(price: number): number {
    return price * 0.7;
  }
}

class NoDiscount implements DiscountStrategy {
  calculateDiscount(price: number): number {
    return price;
  }
}

// Strategy selector class
class DiscountManager {
  private strategies: Map;

  constructor() {
    this.strategies = new Map();
    // Register default strategies
    this.registerStrategy('regular', new RegularCustomerDiscount());
    this.registerStrategy('vip', new VIPCustomerDiscount());
    this.registerStrategy('platinum', new PlatinumCustomerDiscount());
  }

  registerStrategy(customerType: string, strategy: DiscountStrategy): void {
    this.strategies.set(customerType, strategy);
  }

  getDiscountedPrice(customerType: string, price: number): number {
    const strategy = this.strategies.get(customerType) || new NoDiscount();
    return strategy.calculateDiscount(price);
  }
}

// Usage
const discountManager = new DiscountManager();

// Extend by adding a new strategy
discountManager.registerStrategy('gold', {
  calculateDiscount(price: number): number {
    return price * 0.75;
  }
});

console.log(discountManager.getDiscountedPrice('vip', 100)); // 80
console.log(discountManager.getDiscountedPrice('gold', 100)); // 75

🔄 FP vs OOP Evaluation for OCP

FP Advantages:

More concise with less boilerplate
Strategy implementation is just a function, not a class
Easier to add new strategies with simple assignment
Behavior is separated from data structure

OOP Advantages:

Explicit strategy interface enforces contract
Can encapsulate more complex behavior in strategy classes
Strategy registration is centralized and controlled
Can include additional methods or properties in strategies if needed

Better for Node.js context:

FP is better for simpler strategies - When the discount logic is straightforward, the function map is more concise
OOP is better for complex strategies - When strategies have state or multiple related operations, classes provide better organization

✅ 3. Liskov Substitution Principle (LSP)

Functions that use pointers or references to base types must be able to use objects of derived types without knowing it.

❌ Wrong Approach

class Bird {
  fly() {
    console.log('Flying');
  }
}

class Penguin extends Bird {
  fly() {
    throw new Error("Penguins can't fly!");
  }
}

Why this is wrong:

The Penguin class inherits from Bird but overrides the fly() method to throw an error
This violates client expectations - code using a Bird object can't safely substitute a Penguin
Any function that expects all birds to fly will break when using a Penguin
The inheritance hierarchy doesn't reflect the true capabilities of the objects
This forces client code to check object types before calling methods, which defeats the purpose of polymorphism

✅ Functional TypeScript Approach

// Define capability interfaces
interface Flyer {
  fly: () => void;
}

interface Swimmer {
  swim: () => void;
}

interface Egg {
  layEgg: () => void;
}

// Type predicates for runtime checking
const isFlyer = (animal: any): animal is Flyer => 
  typeof animal.fly === 'function';

// Factory functions instead of classes
const createBird = (name: string): Egg => ({
  layEgg: () => console.log(`${name} is laying an egg`)
});

const createFlyingBird = (name: string): Flyer & Egg => ({
  ...createBird(name),
  fly: () => console.log(`${name} is flying`)
});

const createSwimmingBird = (name: string): Swimmer & Egg => ({
  ...createBird(name),
  swim: () => console.log(`${name} is swimming`)
});

// Safe function that works with the appropriate type
const letBirdFly = (bird: Flyer): void => {
  bird.fly();
};

// Factory functions for specific birds
const createSparrow = (name: string) => createFlyingBird(name);
const createPenguin = (name: string) => createSwimmingBird(name);

// Usage
const sparrow = createSparrow('Sparky');
const penguin = createPenguin('Pingu');

letBirdFly(sparrow); // Works fine
// letBirdFly(penguin); // TypeScript error - penguin doesn't implement Flyer

✅ Well-Designed OOP TypeScript Approach

// Base interfaces for capabilities
interface EggLayer {
  layEgg(): void;
}

interface Flyer {
  fly(): void;
}

interface Swimmer {
  swim(): void;
}

// Base class with shared behavior
abstract class Bird implements EggLayer {
  constructor(protected name: string) {}

  layEgg(): void {
    console.log(`${this.name} is laying an egg`);
  }
}

// Flying birds
class FlyingBird extends Bird implements Flyer {
  constructor(name: string) {
    super(name);
  }

  fly(): void {
    console.log(`${this.name} is flying`);
  }
}

// Swimming birds
class SwimmingBird extends Bird implements Swimmer {
  constructor(name: string) {
    super(name);
  }

  swim(): void {
    console.log(`${this.name} is swimming`);
  }
}

// Specific bird types
class Sparrow extends FlyingBird {
  constructor(name: string) {
    super(name);
  }
}

class Penguin extends SwimmingBird {
  constructor(name: string) {
    super(name);
  }
}

// Safe function that works with the appropriate type
function letBirdFly(bird: Flyer): void {
  bird.fly();
}

// Usage
const sparrow = new Sparrow('Sparky');
const penguin = new Penguin('Pingu');

letBirdFly(sparrow); // Works fine
// letBirdFly(penguin); // TypeScript error - penguin doesn't implement Flyer

🔄 FP vs OOP Evaluation for LSP

FP Advantages:

Composition over inheritance prevents LSP violations
Interface-based programming fits TypeScript's structural typing well
No complex inheritance hierarchies to manage
Easier to combine multiple behaviors (like Flyer & EggLayer)

OOP Advantages:

Clear is-a relationships when they truly exist
Better encapsulation of private methods and state
Abstract classes can provide shared implementation
Familiar to developers from OOP backgrounds

Better for Node.js context:

FP is better for behavior-focused applications - When the focus is on what things can do rather than what they are
OOP is better for domain modeling - When you need to model real-world entities with clear hierarchies and encapsulated state

✅ 4. Interface Segregation Principle (ISP)

Many client-specific interfaces are better than one general-purpose interface.

❌ Wrong Approach

class Machine {
  print() { throw new Error('Not implemented'); }
  scan() { throw new Error('Not implemented'); }
  fax() { throw new Error('Not implemented'); }
}

class OldPrinter extends Machine {
  print() { console.log('Printing...'); }
  // Must implement unused methods
}

Why this is wrong:

The Machine class forces all subclasses to implement methods they might not need or support
OldPrinter needs to handle scan() and fax() methods even though it can't actually do these things
This leads to "fat" interfaces that burden implementers with methods they don't use
It violates the Interface Segregation Principle by not providing focused, client-specific interfaces
Implementations often resort to throwing errors or empty methods for unsupported functionality

✅ Functional TypeScript Approach

// Small, focused interfaces
interface Printer {
  print: (document: string) => void;
}

interface Scanner {
  scan: () => string;
}

interface Faxer {
  fax: (document: string, recipient: string) => void;
}

// Implementation functions
const createPrinter = (): Printer => ({
  print: (document: string) => console.log(`Printing: ${document}`)
});

const createScanner = (): Scanner => ({
  scan: () => {
    const scannedContent = "Scanned content";
    console.log('Scanning...');
    return scannedContent;
  }
});

const createFaxer = (): Faxer => ({
  fax: (document: string, recipient: string) => 
    console.log(`Faxing ${document} to ${recipient}`)
});

// Composition to create different device types
const createMultiFunctionPrinter = () => ({
  ...createPrinter(),
  ...createScanner(),
  ...createFaxer()
});

const createBasicPrinter = () => createPrinter();

// Usage
const multiFunction = createMultiFunctionPrinter();
const basicPrinter = createBasicPrinter();

multiFunction.print("Report"); // Can use all functions
multiFunction.scan();
multiFunction.fax("Contract", "client@example.com");

basicPrinter.print("Letter"); // Only has print functionality
// basicPrinter.scan(); // TypeScript error - doesn't exist

✅ Well-Designed OOP TypeScript Approach

// Small, focused interfaces
interface Printer {
  print(document: string): void;
}

interface Scanner {
  scan(): string;
}

interface Faxer {
  fax(document: string, recipient: string): void;
}

// Implementation classes
class BasicPrinter implements Printer {
  print(document: string): void {
    console.log(`Printing: ${document}`);
  }
}

class BasicScanner implements Scanner {
  scan(): string {
    console.log('Scanning...');
    return "Scanned content";
  }
}

class BasicFaxer implements Faxer {
  fax(document: string, recipient: string): void {
    console.log(`Faxing ${document} to ${recipient}`);
  }
}

// Composition through delegation
class MultiFunctionPrinter implements Printer, Scanner, Faxer {
  private printer: Printer;
  private scanner: Scanner;
  private faxer: Faxer;

  constructor(
    printer: Printer = new BasicPrinter(),
    scanner: Scanner = new BasicScanner(),
    faxer: Faxer = new BasicFaxer()
  ) {
    this.printer = printer;
    this.scanner = scanner;
    this.faxer = faxer;
  }

  print(document: string): void {
    this.printer.print(document);
  }

  scan(): string {
    return this.scanner.scan();
  }

  fax(document: string, recipient: string): void {
    this.faxer.fax(document, recipient);
  }
}

// Single-function device
class OfficePrinter implements Printer {
  private printer: Printer;

  constructor(printer: Printer = new BasicPrinter()) {
    this.printer = printer;
  }

  print(document: string): void {
    this.printer.print(document);
  }
}

// Usage
const multiFunction = new MultiFunctionPrinter();
const basicPrinter = new OfficePrinter();

multiFunction.print("Report");
multiFunction.scan();
multiFunction.fax("Contract", "client@example.com");

basicPrinter.print("Letter");
// basicPrinter.scan(); // TypeScript error - doesn't exist

🔄 FP vs OOP Evaluation for ISP

FP Advantages:

Simpler object composition with spread operator
Less boilerplate code with no delegation methods
Factory functions can easily combine interfaces
No need to create class hierarchies

OOP Advantages:

Clear separation of interface and implementation
Can have private methods and properties
Dependency injection at constructor level
Can more easily replace specific implementations

Better for Node.js context:

FP is better for lightweight objects - When the implementations are simple and don't need encapsulation
OOP is better for complex components - When components need internal state, private methods, or lifecycle management

✅ 5. Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions.

❌ Wrong Approach

class MySQLDatabase {
  save(data) {
    console.log('Saving data to MySQL:', data);
  }
}

class UserService {
  constructor() {
    this.db = new MySQLDatabase();
  }

  registerUser(user) {
    this.db.save(user);
  }
}

Why this is wrong:

UserService directly depends on the concrete MySQLDatabase class instead of an abstraction
It's impossible to switch to a different database implementation without modifying UserService
Testing becomes difficult as you can't easily mock the database
The high-level module (UserService) is tightly coupled to a low-level implementation detail
This creates inflexible code that's hard to adapt to changing requirements

✅ Functional TypeScript Approach

// Define the abstract interface for database operations
type SaveFn = (data: T) => void;

// Low-level implementations
const createMySQLDatabase = (): { save: SaveFn } => ({
  save: (data: T): void => {
    console.log('Saving data to MySQL:', data);
  }
});

const createInMemoryDatabase = (): { save: SaveFn } => {
  const storage: any[] = [];
  return {
    save: (data: T): void => {
      storage.push(data);
      console.log('Saved in memory:', data);
    }
  };
};

// High-level module that accepts any implementation of the SaveFn abstraction
const createUserService = (saveFunction: SaveFn) => ({
  registerUser: (user: { name: string }) => {
    saveFunction(user);
    return { success: true };
  }
});

// Usage - inject the dependency
const mySqlDb = createMySQLDatabase();
const inMemoryDb = createInMemoryDatabase();

const userServiceWithMySQL = createUserService(mySqlDb.save);
const userServiceWithInMemory = createUserService(inMemoryDb.save);

userServiceWithMySQL.registerUser({ name: 'Alice' });
userServiceWithInMemory.registerUser({ name: 'Bob' });

// For testing - inject a mock
const mockSave: SaveFn = (data: T) => {
  console.log('Mock save called');
};

const testableUserService = createUserService(mockSave);
testableUserService.registerUser({ name: 'Test User' });

✅ Well-Designed OOP TypeScript Approach

// Abstract database interface
interface Database {
  save(data: T): void;
}

// Concrete implementations
class MySQLDatabase implements Database {
  save(data: T): void {
    console.log('Saving data to MySQL:', data);
  }
}

class InMemoryDatabase implements Database {
  private storage: any[] = [];

  save(data: T): void {
    this.storage.push(data);
    console.log('Saved in memory:', data);
  }
}

// High-level module depending on abstraction
class UserService {
  private db: Database;

  constructor(db: Database) {
    this.db = db;
  }

  registerUser(user: { name: string }): { success: boolean } {
    this.db.save(user);
    return { success: true };
  }
}

// Usage - inject the dependency
const userServiceWithMySQL = new UserService(new MySQLDatabase());
const userServiceWithInMemory = new UserService(new InMemoryDatabase());

userServiceWithMySQL.registerUser({ name: 'Alice' });
userServiceWithInMemory.registerUser({ name: 'Bob' });

// For testing - inject a mock
class MockDatabase implements Database {
  save(data: T): void {
    console.log('Mock save called');
  }
}

const testableUserService = new UserService(new MockDatabase());
testableUserService.registerUser({ name: 'Test User' });

🔄 FP vs OOP Evaluation for DIP

FP Advantages:

Function injection is simpler than class injection
No need for interfaces, just use function types
Easier to mock with simple function replacement
More concise code with less boilerplate

OOP Advantages:

Explicit interface contracts
Can include multiple related methods in one interface
Maintains encapsulation of related functionality
Familiar dependency injection pattern for many developers

Better for Node.js context:

FP is better for simple dependencies - When the dependency only has one or two functions
OOP is better for complex dependencies - When the dependency has multiple related methods or needs to maintain state

📦 Final Thoughts: When to Choose FP vs OOP in TypeScript/Node.js

Both functional and object-oriented approaches can implement SOLID principles effectively in TypeScript. The best choice depends on your specific use case:

Choose Functional Programming when:

Data transformations are the focus - HTTP handlers, data processing pipelines
Simplicity is paramount - Fewer lines of code, less boilerplate
Testing pure functions - Easier to test without mocking frameworks
Concurrency matters - Immutable data and pure functions reduce race conditions
Composition over inheritance - When you need to mix and match behaviors flexibly

Choose Object-Oriented Programming when:

Entity modeling is important - When your domain has clear "is-a" relationships
Encapsulation is needed - For hiding implementation details or internal state
Complex internal state - When objects need to maintain and protect their state
Resource management - When you need constructors/destructors for resources
Framework expectations - When working with OOP-oriented frameworks

Hybrid Approach

Many successful Node.js applications use a hybrid approach:

OOP for services, repositories, and domain models
FP for controllers, utilities, and data transformations
TypeScript interfaces to define contracts between them

🔍 Conclusion: Embracing SOLID Regardless of Paradigm

The SOLID principles remain valuable design guidelines regardless of whether you're using functional or object-oriented programming in TypeScript. What's most important is understanding the underlying principles and applying them appropriately.

Both paradigms have their strengths and weaknesses:

Functional programming excels in simplicity, testability, and explicit data flow
Object-oriented programming shines in encapsulation, modeling real-world entities, and managing complex state

In modern TypeScript and Node.js development, the most effective approach is often a pragmatic blend of both paradigms, leveraging TypeScript's versatility to apply the right tool for each job. By understanding SOLID principles through both lenses, you develop a more nuanced and flexible approach to software design.

Remember that SOLID isn't about dogmatically following rules, but about creating code that's maintainable, testable, and adaptable to change. Whether you choose functional or object-oriented approaches, the SOLID principles provide a valuable framework for thinking about good design.

By analyzing your specific requirements, considering the complexity of your domain, and evaluating the strengths of each paradigm, you can make informed decisions about when to use functional or object-oriented approaches in your TypeScript applications.

Hold on! Good things are coming your way.

Thanks for sticking with me!