SOLID in TypeScript: five principles with before/after code

In short

SOLID is five object-oriented design principles collected by Robert C. Martin: Single Responsibility (S), Open/Closed (O), Liskov Substitution (L), Interface Segregation (I) and Dependency Inversion (D). All five answer one question: how to structure code so that a change in one place does not break others and parts can be tested in isolation. They are heuristics, not laws: every abstraction has a cost, so apply a principle where changes actually happen.

FundamentalsLevel: IntermediateSOLID

After this you will be able to

recognise a violation of each SOLID principle by its symptom: different people edit one class, a switch grows with every feature, a subclass crashes on valid input, a test fake implements five methods, a service creates its own HTTP client
fix the violation in TypeScript with strict on and prove the behaviour is preserved with a node:test test
explain why tsc does not catch a narrowed method parameter and how a contract test checks Liskov substitution
decide when a principle is not worth applying and name the cost of an unnecessary abstraction

Know beforehand

Verified with

TypeScript 7.0.2 (tsc --strict)Node.js 24 LTS (24.18), node:testJava 21 LTS (eclipse-temurin 21.0.12)

Checked against docs: October 11, 2026

Contents

01Why SOLID, and where people overdo it
02S — Single Responsibility
03O — Open for extension, closed for modification
04L — Liskov Substitution
05I — Interface Segregation
06D — Dependency Inversion
07Practice: the notification service after refactoring

Why SOLID, and where people overdo it

Code that works is not necessarily easy to change. A typical story: a notification service started as one "send to Telegram" function, then SMS, email, marketing copy and support logs were added — and every edit started touching its neighbours. SOLID is five principles describing how to distribute responsibilities and dependencies so this does not happen. In his 2020 note "Solid Relevance", Robert C. Martin states them briefly:

Principle	Martin's wording (2020)	Symptom of a violation
S — Single Responsibility	Gather together the things that change for the same reasons; separate things that change for different reasons	Marketing, developers and support all edit one class
O — Open/Closed	A module should be open for extension but closed for modification	Every new variant means editing the same `switch`
L — Liskov Substitution	A program that uses an interface must not be confused by an implementation of that interface	A subclass crashes or behaves differently on the same input
I — Interface Segregation	Keep interfaces small so that users don't depend on things they don't need	A test fake implements five methods for the sake of one
D — Dependency Inversion	Depend in the direction of abstraction; high-level modules should not depend on low-level details	Business logic creates its own HTTP client and reads `process.env`

S — Single Responsibility

Martin's wording (2020): Gather together the things that change for the same reasons; separate things that change for different reasons
Symptom of a violation: Marketing, developers and support all edit one class

O — Open/Closed

Martin's wording (2020): A module should be open for extension but closed for modification
Symptom of a violation: Every new variant means editing the same switch

L — Liskov Substitution

Martin's wording (2020): A program that uses an interface must not be confused by an implementation of that interface
Symptom of a violation: A subclass crashes or behaves differently on the same input

I — Interface Segregation

Martin's wording (2020): Keep interfaces small so that users don't depend on things they don't need
Symptom of a violation: A test fake implements five methods for the sake of one

D — Dependency Inversion

Martin's wording (2020): Depend in the direction of abstraction; high-level modules should not depend on low-level details
Symptom of a violation: Business logic creates its own HTTP client and reads process.env

All examples share one domain: a salon booking service and its notifications. The code is TypeScript, checked by tsc in strict mode and run by Node.js 24 directly, without a build: since 24.12, Node.js strips types from .ts files as a stable feature. Tests use the built-in node:test, no third-party libraries. Every principle has a "before" and an "after" version, and the tests cover both.

bash

npm init -y
npm pkg set type=module
npm install --save-dev typescript@7.0.2 @types/node@24
npx tsc --noEmit
node --test

Project setup: TypeScript only for type checking, Node.js for running and testing

tsconfig.json

{
  "compilerOptions": {
    "target": "esnext",
    "module": "nodenext",
    "strict": true,
    "noEmit": true,
    "erasableSyntaxOnly": true,
    "verbatimModuleSyntax": true,
    "allowImportingTsExtensions": true,
    "noImplicitOverride": true,
    "types": ["node"]
  },
  "include": ["src", "test"],
  "exclude": ["src/lsp/strict-channel.ts"]
}

erasableSyntaxOnly forbids syntax Node.js cannot strip (enums, parameter properties), so the examples declare fields explicitly. The file with an intentional error from the Liskov section is excluded from the main check

src/booking.ts

export type Booking = {
  id: string;
  clientName: string;
  service: string;
  startsAt: Date;
  chatId: string; // Telegram chat of the client
};

The shared booking model for all examples

S — Single Responsibility

"A class should have one reason to change" is often read as "a class does one thing". In his 2014 article Martin clarifies: the reasons for change are people. In his example an Employee class calculates pay (the CFO's concern), reports hours (the COO's) and saves itself to the database (the CTO's). Three different sources of change, three responsibilities. Let us look at the reminder service.

src/srp/reminder-before.ts

import type { Booking } from "../booking.ts";

// One class, three reasons to change: the wording (marketing),
// the delivery channel (developers) and the audit log (operations).
export class ReminderService {
  async remind(booking: Booking): Promise<void> {
    const time = new Intl.DateTimeFormat("en-GB", {
      timeZone: "Asia/Almaty",
      day: "numeric",
      month: "short",
      hour: "2-digit",
      minute: "2-digit",
    }).format(booking.startsAt);
    const text = `${booking.clientName}, see you on ${time}: ${booking.service}`;

    const response = await fetch(
      `https://api.telegram.org/bot${process.env.TELEGRAM_TOKEN}/sendMessage`,
      {
        method: "POST",
        headers: { "content-type": "application/json" },
        body: JSON.stringify({ chat_id: booking.chatId, text }),
      },
    );
    if (!response.ok) throw new Error(`Telegram responded ${response.status}`);

    console.log(`${new Date().toISOString()} reminder sent: ${booking.id}`);
  }
}

Before: wording, delivery and logging in one method

Marketing asks to change the wording — an edit in a class that talks to the network
Moving from Telegram to another channel — an edit in the class that holds the wording
Support asks for a different log format — the same class again
To check the wording, a test has to fake the global fetch and console.log

Split by reasons for change: the wording becomes a pure function, delivery becomes a Telegram client, and the scenario is a service that calls both. The log is passed in as a function, so the service no longer knows where lines go.

src/srp/reminder-after.ts

import type { Booking } from "../booking.ts";

// Wording: changes when marketing rewrites the text.
export function reminderText(booking: Booking): string {
  const time = new Intl.DateTimeFormat("en-GB", {
    timeZone: "Asia/Almaty",
    day: "numeric",
    month: "short",
    hour: "2-digit",
    minute: "2-digit",
  }).format(booking.startsAt);
  return `${booking.clientName}, see you on ${time}: ${booking.service}`;
}

// Delivery: changes when the Telegram API or the channel changes.
export class TelegramClient {
  readonly #token: string;
  readonly #fetch: typeof fetch;

  constructor(token: string, fetchFn: typeof fetch = (input, init) => fetch(input, init)) {
    this.#token = token;
    this.#fetch = fetchFn;
  }

  async sendMessage(chatId: string, text: string): Promise<void> {
    const response = await this.#fetch(
      `https://api.telegram.org/bot${this.#token}/sendMessage`,
      {
        method: "POST",
        headers: { "content-type": "application/json" },
        body: JSON.stringify({ chat_id: chatId, text }),
      },
    );
    if (!response.ok) throw new Error(`Telegram responded ${response.status}`);
  }
}

// Scenario: what happens and in which order. The log is passed in.
export class ReminderService {
  readonly #telegram: TelegramClient;
  readonly #log: (line: string) => void;

  constructor(telegram: TelegramClient, log: (line: string) => void) {
    this.#telegram = telegram;
    this.#log = log;
  }

  async remind(booking: Booking): Promise<void> {
    await this.#telegram.sendMessage(booking.chatId, reminderText(booking));
    this.#log(`reminder sent: ${booking.id}`);
  }
}

After: three parts, each with its own source of change. The default fetch is wrapped in an arrow function: in browsers, calling fetch with a foreign this can throw TypeError "Illegal invocation"

test/srp.test.ts

import { test } from "node:test";
import assert from "node:assert/strict";
import type { Booking } from "../src/booking.ts";
import { ReminderService as ReminderBefore } from "../src/srp/reminder-before.ts";
import { ReminderService, TelegramClient, reminderText } from "../src/srp/reminder-after.ts";

const booking: Booking = {
  id: "b-1",
  clientName: "Aida",
  service: "Haircut",
  startsAt: new Date("2026-10-12T13:00:00Z"), // 18:00 in Almaty (UTC+5)
  chatId: "42",
};

test("before: checking the text means faking global fetch and console", async (t) => {
  const fetchMock = t.mock.method(globalThis, "fetch", async () => new Response("{}"));
  t.mock.method(console, "log", () => {});
  await new ReminderBefore().remind(booking);
  const body = JSON.parse(String(fetchMock.mock.calls[0]?.arguments[1]?.body));
  assert.equal(body.text, "Aida, see you on 12 Oct, 18:00: Haircut");
});

test("after: the wording is a pure function", () => {
  assert.equal(reminderText(booking), "Aida, see you on 12 Oct, 18:00: Haircut");
});

test("after: the scenario runs with a fake fetch and a fake log", async () => {
  const urls: string[] = [];
  const fakeFetch: typeof fetch = async (input) => {
    urls.push(String(input));
    return new Response("{}");
  };
  const lines: string[] = [];
  const service = new ReminderService(new TelegramClient("TEST_TOKEN", fakeFetch), (line) => lines.push(line));

  await service.remind(booking);

  assert.deepEqual(urls, ["https://api.telegram.org/botTEST_TOKEN/sendMessage"]);
  assert.deepEqual(lines, ["reminder sent: b-1"]);
});

test("after: a Telegram error stops the scenario before logging", async () => {
  const failing: typeof fetch = async () => new Response("{}", { status: 502 });
  const lines: string[] = [];
  const service = new ReminderService(new TelegramClient("TEST_TOKEN", failing), (line) => lines.push(line));

  await assert.rejects(service.remind(booking), /Telegram responded 502/);
  assert.deepEqual(lines, []);
});

Tests: the wording is checked without the network, the scenario with a fake fetch, and a Telegram error does not log "sent"

O — Open for extension, closed for modification

Bertrand Meyer formulated the principle in 1988. Martin restates it: you should be able to extend the behaviour of a system without modifying it — the way a code editor gains features through plugins while knowing nothing about them. A typical violation is a function that picks the notification channel with a switch.

src/contact.ts

export type Contact = { phone: string; chatId?: string; email?: string };

// Stand-in for an HTTP client of a messaging provider.
export interface Gateway {
  post(endpoint: string, payload: Record<string, string>): Promise<void>;
}

The client contact and a stub of the provider's HTTP gateway, shared by before and after

src/ocp/notify-before.ts

import type { Contact, Gateway } from "../contact.ts";

export type ChannelName = "sms" | "telegram" | "email";

// Every new channel means editing this union and this switch.
export async function notify(
  channel: ChannelName,
  contact: Contact,
  text: string,
  gateway: Gateway,
): Promise<void> {
  switch (channel) {
    case "sms":
      return gateway.post("sms", { phone: contact.phone, text: text.slice(0, 160) });
    case "telegram":
      if (!contact.chatId) throw new Error("No Telegram chat");
      return gateway.post("telegram", { chat_id: contact.chatId, text });
    case "email":
      if (!contact.email) throw new Error("No email");
      return gateway.post("email", { to: contact.email, subject: "Reminder", text });
  }
}

Before: WhatsApp or push means editing the type, the function and every place that lists channels

The channel-selection rule is scattered too: the caller decides where to send. Move the channel into an interface with two questions — "can you reach this client?" and "send". Notifier walks the channels in priority order and does not know how many there are or what they are.

src/ocp/notify-after.ts

import type { Contact, Gateway } from "../contact.ts";

export interface Channel {
  readonly name: string;
  canReach(contact: Contact): boolean;
  send(contact: Contact, text: string): Promise<void>;
}

// Closed for modification: adding a channel does not touch this class.
export class Notifier {
  readonly #channels: readonly Channel[];

  constructor(channels: readonly Channel[]) {
    this.#channels = channels;
  }

  // Sends through the first channel (in priority order) that can reach the contact.
  async notify(contact: Contact, text: string): Promise<string> {
    const channel = this.#channels.find((c) => c.canReach(contact));
    if (!channel) throw new Error("No channel can reach this contact");
    await channel.send(contact, text);
    return channel.name;
  }
}

// Open for extension: each channel is a separate object.
export const telegramChannel = (gateway: Gateway): Channel => ({
  name: "telegram",
  canReach: (contact) => Boolean(contact.chatId),
  send: (contact, text) => gateway.post("telegram", { chat_id: contact.chatId ?? "", text }),
});

export const smsChannel = (gateway: Gateway): Channel => ({
  name: "sms",
  canReach: (contact) => contact.phone.length > 0,
  send: (contact, text) => gateway.post("sms", { phone: contact.phone, text: text.slice(0, 160) }),
});

After: a new channel is a new object in the list; Notifier does not change

test/ocp.test.ts

import { test } from "node:test";
import assert from "node:assert/strict";
import type { Contact, Gateway } from "../src/contact.ts";
import { notify } from "../src/ocp/notify-before.ts";
import { Notifier, smsChannel, telegramChannel, type Channel } from "../src/ocp/notify-after.ts";

function recordingGateway() {
  const calls: string[] = [];
  const gateway: Gateway = {
    post: async (endpoint, payload) => {
      calls.push(`${endpoint} ${JSON.stringify(payload)}`);
    },
  };
  return { gateway, calls };
}

const withChat: Contact = { phone: "+77010000000", chatId: "42" };
const phoneOnly: Contact = { phone: "+77010000000" };

test("before: the caller picks the channel and the switch knows every channel", async () => {
  const { gateway, calls } = recordingGateway();
  await notify("sms", phoneOnly, "x".repeat(200), gateway);
  assert.equal(calls.length, 1);
  assert.match(calls[0] ?? "", /^sms .*"text":"x{160}"/);
});

test("after: Telegram first, SMS as a fallback", async () => {
  const { gateway, calls } = recordingGateway();
  const notifier = new Notifier([telegramChannel(gateway), smsChannel(gateway)]);

  assert.equal(await notifier.notify(withChat, "Hi"), "telegram");
  assert.equal(await notifier.notify(phoneOnly, "Hi"), "sms");
  assert.deepEqual(calls, [
    'telegram {"chat_id":"42","text":"Hi"}',
    'sms {"phone":"+77010000000","text":"Hi"}',
  ]);
});

test("after: a new channel is added without editing Notifier", async () => {
  const { gateway, calls } = recordingGateway();
  const whatsapp: Channel = {
    name: "whatsapp",
    canReach: (contact) => contact.phone.startsWith("+7"),
    send: (contact, text) => gateway.post("whatsapp", { to: contact.phone, text }),
  };
  const notifier = new Notifier([telegramChannel(gateway), whatsapp, smsChannel(gateway)]);

  assert.equal(await notifier.notify(phoneOnly, "Hi"), "whatsapp");
  assert.deepEqual(calls, ['whatsapp {"to":"+77010000000","text":"Hi"}']);
});

test("after: no suitable channel is an explicit error", async () => {
  const notifier = new Notifier([]);
  await assert.rejects(notifier.notify(phoneOnly, "Hi"), /No channel can reach this contact/);
});

The test adds WhatsApp right in the test file — without a single edit to notify-after.ts

L — Liskov Substitution

The principle is named after Barbara Liskov. Martin's wording: a program that uses an interface must not be confused by an implementation of that interface. Every implementation must accept everything the contract accepts and return what it promises. Martin stresses that this is about subtyping, not inheritance: the principle applies to duck typing and to TypeScript's structural types alike.

src/lsp/message.ts

export type Message =
  | { kind: "text"; text: string }
  | { kind: "image"; url: string; caption: string };

export type TextMessage = Extract<Message, { kind: "text" }>;

// Contract: accepts any Message and resolves with a delivery id.
export interface Channel {
  send(to: string, message: Message): Promise<string>;
}

The channel contract: any message — text or image. In this teaching example channels return a description of the delivery instead of making a real request

src/lsp/channels-before.ts

import type { Channel, Message, TextMessage } from "./message.ts";

export class TelegramChannel implements Channel {
  async send(to: string, message: Message): Promise<string> {
    return message.kind === "text" ? `tg:${to}:${message.text}` : `tg-photo:${to}:${message.url}`;
  }
}

// Compiles: parameters of methods are not checked strictly, so narrowing
// Message to TextMessage goes unnoticed. An image will crash at runtime.
export class SmsChannel implements Channel {
  async send(to: string, message: TextMessage): Promise<string> {
    return `sms:${to}:${message.text.slice(0, 160)}`;
  }
}

export function broadcast(channels: Channel[], to: string, message: Message): Promise<string[]> {
  return Promise.all(channels.map((channel) => channel.send(to, message)));
}

Before: SmsChannel narrowed the parameter to text. tsc --strict reports nothing

Why is the compiler silent with strict on? The strictFunctionTypes flag checks parameters strictly only for functions written in function syntax. For methods the check is relaxed — the TypeScript docs explain that otherwise a large number of existing class hierarchies, including some in the DOM, would break. Write the same contract as a function-typed property and the compiler catches the violation:

src/lsp/strict-channel.ts

import type { Message, TextMessage } from "./message.ts";

// Property syntax: with strict (strictFunctionTypes) the compiler
// checks the parameter and rejects the narrowed implementation.
interface StrictChannel {
  send: (to: string, message: Message) => Promise<string>;
}

export const sms: StrictChannel = {
  send: async (to: string, message: TextMessage) => `sms:${to}:${message.text}`,
};

A teaching file with an intentional error. Checked by a separate tsconfig.lsp-demo.json that extends the main one and includes only this file

terminal

$ npx tsc -p tsconfig.lsp-demo.json
src/lsp/strict-channel.ts(10,3): error TS2322: Type '(to: string, message: TextMessage) => Promise<string>' is not assignable to type '(to: string, message: Message) => Promise<string>'.
  Types of parameters 'message' and 'message' are incompatible.
    Type 'Message' is not assignable to type '{ kind: "text"; text: string; }'.
      Property 'text' is missing in type '{ kind: "image"; url: string; caption: string; }' but required in type '{ kind: "text"; text: string; }'.

Actual tsc 7.0.2 output

Even a function-typed property only protects types. Liskov substitution is broader: an implementation must not strengthen preconditions ("short text only"), weaken postconditions ("sometimes I silently don't send") or throw exceptions the contract does not promise. The compiler cannot see that, so the contract is checked by a test that runs against every implementation. The fixed SMS channel accepts any message: it cannot send a picture, so it sends the caption and a link.

src/lsp/channels-after.ts

import type { Channel, Message } from "./message.ts";

// Keeps the contract: accepts every kind of Message.
// SMS cannot carry a picture, so it sends the caption and a link.
export class SmsChannel implements Channel {
  async send(to: string, message: Message): Promise<string> {
    const text = message.kind === "text" ? message.text : `${message.caption} ${message.url}`;
    return `sms:${to}:${text.slice(0, 160)}`;
  }
}

After: the contract holds for every kind of message

test/lsp.test.ts

import { test } from "node:test";
import assert from "node:assert/strict";
import type { Channel, Message } from "../src/lsp/message.ts";
import { SmsChannel as SmsBefore, TelegramChannel, broadcast } from "../src/lsp/channels-before.ts";
import { SmsChannel } from "../src/lsp/channels-after.ts";

const image: Message = { kind: "image", url: "https://example.com/promo.jpg", caption: "-20% today" };
const text: Message = { kind: "text", text: "See you at 18:00" };

test("before: the narrowed SmsChannel breaks broadcast at runtime", async () => {
  await assert.rejects(broadcast([new TelegramChannel(), new SmsBefore()], "42", image), TypeError);
});

// One contract test for every implementation: this is how LSP is checked.
const channels: [string, Channel][] = [
  ["telegram", new TelegramChannel()],
  ["sms", new SmsChannel()],
];
for (const [name, channel] of channels) {
  for (const message of [text, image]) {
    test(`contract: ${name} accepts ${message.kind} messages`, async () => {
      const id = await channel.send("42", message);
      assert.equal(typeof id, "string");
      assert.ok(id.length > 0);
    });
  }
}

test("after: SMS sends the caption and a link instead of a picture", async () => {
  assert.equal(await new SmsChannel().send("42", image), "sms:42:-20% today https://example.com/promo.jpg");
});

A contract test: the same checks for every implementation. A new channel is added to the array and is checked immediately

I — Interface Segregation

A messaging provider's SDK usually does everything: SMS, email, push, delivery status, balance. If the one-time-code service depends on the whole SDK, it "knows" about five methods while calling one. Martin puts it this way: keep interfaces small so that users don't end up depending on things they don't need.

src/isp/provider.ts

// The full surface of a messaging provider, the way its SDK exposes it.
export interface MessagingProvider {
  sendSms(phone: string, text: string): Promise<void>;
  sendEmail(to: string, subject: string, html: string): Promise<void>;
  sendPush(deviceToken: string, title: string, body: string): Promise<void>;
  deliveryStatus(messageId: string): Promise<"pending" | "delivered" | "failed">;
  balance(): Promise<number>;
}

The provider's full surface, as the SDK exposes it

src/isp/otp-before.ts

import type { MessagingProvider } from "./provider.ts";

// Needs one method, depends on all five.
export class OtpService {
  readonly #provider: MessagingProvider;

  constructor(provider: MessagingProvider) {
    this.#provider = provider;
  }

  async sendCode(phone: string, code: string): Promise<void> {
    await this.#provider.sendSms(phone, `Your code: ${code}`);
  }
}

Before: OtpService depends on five methods and uses one

The cost shows in the test: the fake must implement all five methods. Worse, any change to the unused methods — a new parameter on sendPush — forces you to recheck OtpService as well. Martin Fowler calls a small interface defined from the consumer's side a role interface and notes that role interfaces follow this principle.

src/isp/otp-after.ts

// A role interface: exactly what this client needs, owned by the client.
export interface SmsSender {
  sendSms(phone: string, text: string): Promise<void>;
}

export class OtpService {
  readonly #sms: SmsSender;

  constructor(sms: SmsSender) {
    this.#sms = sms;
  }

  async sendCode(phone: string, code: string): Promise<void> {
    await this.#sms.sendSms(phone, `Your code: ${code}`);
  }
}

After: the interface is declared next to the client and contains exactly what it needs

test/isp.test.ts

import { test } from "node:test";
import assert from "node:assert/strict";
import type { MessagingProvider } from "../src/isp/provider.ts";
import { OtpService as OtpBefore } from "../src/isp/otp-before.ts";
import { OtpService, type SmsSender } from "../src/isp/otp-after.ts";

test("before: the fake has to implement all five methods", async () => {
  const sent: string[] = [];
  const fake: MessagingProvider = {
    sendSms: async (phone, text) => {
      sent.push(`${phone} ${text}`);
    },
    sendEmail: async () => assert.fail("not used"),
    sendPush: async () => assert.fail("not used"),
    deliveryStatus: async () => assert.fail("not used"),
    balance: async () => assert.fail("not used"),
  };
  await new OtpBefore(fake).sendCode("+77010000000", "4821");
  assert.deepEqual(sent, ["+77010000000 Your code: 4821"]);
});

test("after: the fake is one method", async () => {
  const sent: string[] = [];
  const fake: SmsSender = {
    sendSms: async (phone, text) => {
      sent.push(`${phone} ${text}`);
    },
  };
  await new OtpService(fake).sendCode("+77010000000", "4821");
  assert.deepEqual(sent, ["+77010000000 Your code: 4821"]);
});

test("after: the full provider still fits SmsSender, no implements needed", async () => {
  const sent: string[] = [];
  const provider: MessagingProvider = {
    sendSms: async (phone) => {
      sent.push(phone);
    },
    sendEmail: async () => {},
    sendPush: async () => {},
    deliveryStatus: async () => "delivered",
    balance: async () => 100,
  };
  await new OtpService(provider).sendCode("+77010000000", "4821");
  assert.deepEqual(sent, ["+77010000000"]);
});

The fake is one method. The full provider fits without implements: TypeScript compares types structurally

D — Dependency Inversion

High-level policy — the rule "you cannot book the same slot twice" — should not depend on a low-level detail such as an HTTP request to Telegram. In the "before" version, the booking service creates the Telegram client itself and reads the token from the environment.

src/dip/booking-before.ts

import type { Booking } from "../booking.ts";
import { TelegramClient } from "../srp/reminder-after.ts";

// High-level policy creates and depends on a low-level detail.
export class BookingService {
  readonly #bookings = new Map<string, Booking>();
  readonly #telegram = new TelegramClient(process.env.TELEGRAM_TOKEN ?? "");

  async book(booking: Booking): Promise<void> {
    if (this.#bookings.has(booking.id)) throw new Error(`Already booked: ${booking.id}`);
    this.#bookings.set(booking.id, booking);
    await this.#telegram.sendMessage(booking.chatId, `Booked: ${booking.service}`);
  }
}

Before: the booking rule cannot be tested without faking the network

Inversion takes two steps. First, the booking module declares an abstraction in its own terms — "a booking was confirmed", not "send a Telegram message". Schuchert phrases this as capturing low-level dependencies in domain-relevant abstractions. Second, the detail (Telegram) implements that abstraction, so it now depends on the booking module rather than the other way round. Wiring happens in one place — the composition root.

src/dip/booking-service.ts

import type { Booking } from "../booking.ts";

// The abstraction belongs to the booking module and speaks its language:
// "a booking was confirmed", not "send a Telegram message".
export interface BookingNotifier {
  bookingConfirmed(booking: Booking): Promise<void>;
}

export class BookingService {
  readonly #bookings = new Map<string, Booking>();
  readonly #notifier: BookingNotifier;

  constructor(notifier: BookingNotifier) {
    this.#notifier = notifier;
  }

  async book(booking: Booking): Promise<void> {
    if (this.#bookings.has(booking.id)) throw new Error(`Already booked: ${booking.id}`);
    this.#bookings.set(booking.id, booking);
    await this.#notifier.bookingConfirmed(booking);
  }
}

The abstraction belongs to the booking module

src/dip/telegram-notifier.ts

import type { Booking } from "../booking.ts";
import type { BookingNotifier } from "./booking-service.ts";
import type { TelegramClient } from "../srp/reminder-after.ts";

// The detail depends on the abstraction, not the other way round.
export class TelegramBookingNotifier implements BookingNotifier {
  readonly #telegram: TelegramClient;

  constructor(telegram: TelegramClient) {
    this.#telegram = telegram;
  }

  bookingConfirmed(booking: Booking): Promise<void> {
    return this.#telegram.sendMessage(booking.chatId, `Booked: ${booking.service}`);
  }
}

The detail depends on the abstraction

src/dip/composition-root.ts

import { BookingService } from "./booking-service.ts";
import { TelegramBookingNotifier } from "./telegram-notifier.ts";
import { TelegramClient } from "../srp/reminder-after.ts";

// The only place that knows which implementations are used.
export function createBookingService(token: string, fetchFn?: typeof fetch): BookingService {
  return new BookingService(new TelegramBookingNotifier(new TelegramClient(token, fetchFn)));
}

The only place where the implementation is chosen

test/dip.test.ts

import { test } from "node:test";
import assert from "node:assert/strict";
import type { Booking } from "../src/booking.ts";
import { BookingService as BookingBefore } from "../src/dip/booking-before.ts";
import { BookingService, type BookingNotifier } from "../src/dip/booking-service.ts";
import { createBookingService } from "../src/dip/composition-root.ts";

const booking: Booking = {
  id: "b-1",
  clientName: "Aida",
  service: "Haircut",
  startsAt: new Date("2026-10-12T13:00:00Z"),
  chatId: "42",
};

test("before: without a network fake the rule cannot be tested", async (t) => {
  t.mock.method(globalThis, "fetch", async () => new Response("{}", { status: 401 }));
  await assert.rejects(new BookingBefore().book(booking), /Telegram responded 401/);
});

test("after: the rule is tested with an in-memory notifier", async () => {
  const confirmed: string[] = [];
  const notifier: BookingNotifier = {
    bookingConfirmed: async (b) => {
      confirmed.push(b.id);
    },
  };
  const service = new BookingService(notifier);

  await service.book(booking);
  await assert.rejects(service.book(booking), /Already booked: b-1/);
  assert.deepEqual(confirmed, ["b-1"]);
});

test("composition root wires Telegram in", async () => {
  const urls: string[] = [];
  const fakeFetch: typeof fetch = async (input) => {
    urls.push(String(input));
    return new Response("{}");
  };
  await createBookingService("TEST_TOKEN", fakeFetch).book(booking);
  assert.deepEqual(urls, ["https://api.telegram.org/botTEST_TOKEN/sendMessage"]);
});

The "no double booking" rule is tested without the network; a separate test checks that the composition root wires in Telegram

Dependency injection (DI) and dependency inversion are not the same. Schuchert separates them: DI is about wiring, DIP is about the shape of the abstraction. Injecting a raw HTTP client into a service is DI but not DIP: the service still depends on a detail, it just receives it through the constructor. In Spring and NestJS a container does the wiring, and the principle looks the same. Here is the same design in Java 21:

BookingDemo.java

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

public class BookingDemo {
    record Booking(String id, String chatId, String service) {}

    // Owned by the booking module, named in its terms.
    interface BookingNotifier {
        void bookingConfirmed(Booking booking);
    }

    static final class BookingService {
        private final Map<String, Booking> bookings = new HashMap<>();
        private final BookingNotifier notifier;

        BookingService(BookingNotifier notifier) {
            this.notifier = notifier;
        }

        void book(Booking booking) {
            if (bookings.putIfAbsent(booking.id(), booking) != null) {
                throw new IllegalStateException("Already booked: " + booking.id());
            }
            notifier.bookingConfirmed(booking);
        }
    }

    public static void main(String[] args) {
        List<Booking> confirmed = new ArrayList<>();
        // A one-method interface is satisfied by a lambda or a method reference.
        var service = new BookingService(confirmed::add);

        service.book(new Booking("b-1", "42", "Haircut"));
        try {
            service.book(new Booking("b-1", "42", "Haircut"));
            throw new AssertionError("duplicate must be rejected");
        } catch (IllegalStateException expected) {
            System.out.println(expected.getMessage());
        }
        if (confirmed.size() != 1) throw new AssertionError("expected one confirmation");
        System.out.println("confirmations: " + confirmed.size());
    }
}

A single-method interface is implemented by a lambda or a method reference — a one-line test fake

terminal

$ javac -encoding UTF-8 -d out BookingDemo.java && java -cp out BookingDemo
Already booked: b-1
confirmations: 1

Actual output in the eclipse-temurin:21 Docker image (OpenJDK 21.0.12)

Practice: the notification service after refactoring

Let us put it together. After refactoring, the notification service keeps wording apart from delivery (S), adds channels without editing Notifier (O), runs every channel through a shared contract test (L), makes services depend on small role interfaces (I), and makes booking rules depend on an abstraction that Telegram implements (D). Checking the whole project takes two commands:

terminal

$ npx tsc --noEmit && node --test
✔ before: without a network fake the rule cannot be tested
✔ after: the rule is tested with an in-memory notifier
✔ composition root wires Telegram in
✔ exercise: email goes between Telegram and SMS
✔ before: the fake has to implement all five methods
✔ after: the fake is one method
✔ after: the full provider still fits SmsSender, no implements needed
✔ before: the narrowed SmsChannel breaks broadcast at runtime
✔ contract: telegram accepts text messages
✔ contract: telegram accepts image messages
✔ contract: sms accepts text messages
✔ contract: sms accepts image messages
✔ after: SMS sends the caption and a link instead of a picture
✔ before: the caller picks the channel and the switch knows every channel
✔ after: Telegram first, SMS as a fallback
✔ after: a new channel is added without editing Notifier
✔ after: no suitable channel is an explicit error
✔ before: checking the text means faking global fetch and console
✔ after: the wording is a pure function
✔ after: the scenario runs with a fake fetch and a fake log
✔ after: a Telegram error stops the scenario before logging
ℹ tests 21
ℹ suites 0
ℹ pass 21
ℹ fail 0
ℹ cancelled 0
ℹ skipped 0
ℹ todo 0

Actual output: 21 tests covering both versions of every example and the solution to the first exercise. Test timings removed

Principle	What changed in the code	What proves it
S	`reminderText`, `TelegramClient`, `ReminderService` instead of one method	The wording is tested without faking the network
O	A `Channel` interface and a list of channels instead of a `switch`	WhatsApp added in a test without editing `Notifier`
L	The SMS channel accepts any message	A contract test over all implementations
I	`SmsSender` instead of the full `MessagingProvider`	A one-method fake
D	`BookingNotifier` in the booking module, Telegram as an implementation	The booking rule is tested without the network

What changed in the code: reminderText, TelegramClient, ReminderService instead of one method
What proves it: The wording is tested without faking the network

What changed in the code: A Channel interface and a list of channels instead of a switch
What proves it: WhatsApp added in a test without editing Notifier

What changed in the code: The SMS channel accepts any message
What proves it: A contract test over all implementations

What changed in the code: SmsSender instead of the full MessagingProvider
What proves it: A one-method fake

What changed in the code: BookingNotifier in the booking module, Telegram as an implementation
What proves it: The booking rule is tested without the network

RepeatAn email channel without editing Notifier

Add an email channel that applies when the contact has an email and sits between Telegram and SMS in priority. You may not edit notify-after.ts. Write a test.

Hint

A channel is an object with name, canReach and send. Priority is the order of the array passed to Notifier.

Solution

Plug it in at the composition root: new Notifier([telegramChannel(g), emailChannel(g), smsChannel(g)]). The solution is covered by a test in the output above.

TypeScript

import type { Gateway } from "../contact.ts";
import type { Channel } from "../ocp/notify-after.ts";

export const emailChannel = (gateway: Gateway): Channel => ({
  name: "email",
  canReach: (contact) => Boolean(contact.email),
  send: (contact, text) =>
    gateway.post("email", { to: contact.email ?? "", subject: "Reminder", text }),
});

Next step: design patterns — Strategy, Adapter, Observer and other ready-made solutions that implement these principles. The channels from the Open/Closed section are already the Strategy pattern.

How this was verified3 · passed1 · not runchecked 11 October 2026

“Run” means the code was executed in a scratch project or container and the output in the article comes from that run. “Partial” means it was checked against stubs instead of external services. “Not run” means it needs a device, an account or a key; the steps were checked against the official documentation. The verification project files and run logs are kept in the InterLAB archive.

SOLID with clear examples

Why SOLID, and where people overdo it

S — Single Responsibility

O — Open for extension, closed for modification

L — Liskov Substitution

I — Interface Segregation

D — Dependency Inversion

Practice: the notification service after refactoring

Sources

Custom Software Development

OOP: classes, encapsulation, inheritance and composition

Design patterns you actually need

Clean architecture: dependencies point inward, module boundaries

Backend application layers: controller, service, repository

Software architecture: what it is and which decisions belong to it

Got a project?
We'll scope and estimate it — for free.

01Why SOLID, and where people overdo it

02S — Single Responsibility

03O — Open for extension, closed for modification

04L — Liskov Substitution

05I — Interface Segregation

06D — Dependency Inversion

07Practice: the notification service after refactoring

Sources

Custom Software Development

OOP: classes, encapsulation, inheritance and composition

Design patterns you actually need

Clean architecture: dependencies point inward, module boundaries

Backend application layers: controller, service, repository

Software architecture: what it is and which decisions belong to it

Got a project?We'll scope and estimate it — for free.

Why SOLID, and where people overdo it

S — Single Responsibility

O — Open for extension, closed for modification

L — Liskov Substitution

I — Interface Segregation

D — Dependency Inversion

Practice: the notification service after refactoring

Got a project?
We'll scope and estimate it — for free.