The SOLID principles that look alike

Published 21 October 2026

Read the five SOLID principles in a row and they blur together. Split this class. Split that interface. Depend on less. Depend on abstractions. It sounds like one rule ("make things smaller and less tangled") said five ways, and in an interview that blur shows up as "ISP is basically SRP for interfaces", which is the answer that gets a follow up question.

A doctor has the same problem. Fever, headache and tiredness turn up in dozens of illnesses. The symptom does not tell you the cause, so the doctor asks a different question for each one. The SOLID principles share symptoms (code that is painful to change) but each one names a different cause, and each one is a question you can ask about a piece of code.

Five principles, five questions#

Keep this table in your head and most of the confusion goes away. Try it on six cases from the same food delivery codebase:

class OrderService {
  placeOrder(cart: Cart) { /* orders team */ }
  gstFor(total: number) { /* finance */ }
  invoicePdf(order: Order) { /* design */ }
}

interface Staff {
  cook(): void; serve(): void
  deliver(): void; cleanTable(): void
}
function assignDelivery(rider: Staff) {
  rider.deliver()
}

class Discount {
  // promise: never returns less than 0
  apply(total: number) { return total }
}
class Flat50 extends Discount {
  apply(total: number) { return total - 50 }
}

function deliveryFee(vehicle: string, km: number) {
  if (vehicle === 'bike') return 20 + 5 * km
  else if (vehicle === 'cycle') return 10 + 4 * km
  else if (vehicle === 'ecycle') return 12 + 4 * km
  throw new Error('unknown vehicle')
}

class OrderService {
  private sms = new Msg91Client('key_live_8f2a')
  placeOrder(phone: string) {
    this.sms.send(phone, 'Order confirmed')
  }
}

interface OrderApi {
  status(id: string): string
  setStatus(id: string, s: string): void
  refund(id: string): void
  exportCsv(month: string): string
}

S vs I: who changes it, or who uses it#

Both say "split it". They split different things, for different people.

• Single responsibility is about the implementation, seen from the people who ask for changes. A class has one responsibility when one group of people (one team, one part of the business) is the reason it changes. Finance, design and the orders team all editing OrderService is a single responsibility problem.
• Interface segregation is about the contract, seen from the callers. A caller should be handed only the methods it uses, so a change to the others cannot touch it.

They are independent. Here is a class where ISP is fine and SRP is broken:

interface OrderStatus {
  status(id: string): string
}
interface Refunds {
  refund(id: string): string
}
 
// ISP is fine: each caller is handed only what it needs.
// SRP is not: the kitchen team and finance both edit this class.
class OrderDesk implements OrderStatus, Refunds {
  status(id: string) {
    return `${id}: preparing`
  }
  refund(id: string) {
    return `${id}: refunded, 2% fee kept`
  }
}
 
function kitchenScreen(orders: OrderStatus) {
  return orders.status('A17')
}
 
console.log(kitchenScreen(new OrderDesk())) // A17: preparing

The kitchen screen asks for OrderStatus and knows nothing about refunds, so ISP is happy. But when finance changes the refund fee, they edit the same file the kitchen team edits, and their pull requests collide. Split the class by team (KitchenOrders, RefundService) to fix SRP. The reverse also happens: one tidy class with a single owner, handed to callers through one huge interface. That is an ISP problem with no SRP problem.

So back to the question at the top. OrderService with three teams' methods breaks S. It only breaks I as well if some caller is handed the whole class and uses one method of it.

L vs I: a broken promise, or too big a promise#

These two get confused because the classic ISP example ends in a Liskov bug. A Staff interface has cook, serve and deliver. A Rider has to implement all three, so cook() throws "riders do not cook". Now any code that is handed a Staff and calls cook() can blow up.

• The throw is the Liskov violation: something that claims to be a Staff does not behave like one.
• The reason it had to throw is the ISP violation: the interface demanded something a rider can never do.

Fix the interface and the throw has no reason to exist. But Liskov is wider than that, and it does not need an interface at all. It is about behaviour, and the compiler cannot check it:

class Discount {
  // Promise to every caller: never returns less than 0.
  apply(total: number) {
    return total
  }
}
 
class Flat50 extends Discount {
  override apply(total: number) {
    return total - 50
  }
}
 
function bill(total: number, discount: Discount) {
  return discount.apply(total)
}
 
console.log(bill(30, new Flat50())) // -20

This compiles cleanly. The shapes match, the interface is tiny, and ISP has nothing to say. It still breaks every caller that trusted the parent's promise, and on a ₹30 cart it sent a negative amount to the payment gateway. The fix keeps the promise:

class Discount {
  apply(total: number) {
    return total
  }
}
 
class Flat50 extends Discount {
  override apply(total: number) {
    return Math.max(0, total - 50)
  }
}
 
console.log(new Flat50().apply(30)) // 0
console.log(new Flat50().apply(300)) // 250

A quick test for Liskov: write a test against the parent, then run the same test against every child. If a child fails a test the parent passes, it is not a real substitute.

O vs D: the goal, or the direction of the arrow#

These two are confused because the fix for both is usually "add an interface".

• Open closed is a goal: you can add a new kind of thing (a new SMS vendor, a new vehicle type, a new discount) by adding code, without editing code that already works.
• Dependency inversion is a structure: high level code (business rules) does not import low level code (vendors, databases). Both depend on an abstraction, and the abstraction belongs to the high level side.

interface Notifier {
  send(phone: string, text: string): string
}
 
class OrderService {
  constructor(private notifier: Notifier) {}
 
  placeOrder(phone: string) {
    return this.notifier.send(phone, 'Order confirmed')
  }
}
 
// D: OrderService names Notifier and nothing else.
// O: a new channel is a new object. OrderService is not edited.
const sms: Notifier = { send: (p, t) => `SMS ${p}: ${t}` }
const whatsapp: Notifier = { send: (p, t) => `WhatsApp ${p}: ${t}` }
 
const viaSms = new OrderService(sms).placeOrder('98100')
const viaWhatsapp = new OrderService(whatsapp).placeOrder('98100')
console.log(viaSms) // SMS 98100: Order confirmed
console.log(viaWhatsapp) // WhatsApp 98100: Order confirmed

Inverting the dependency is the most common way to get open closed, but they are not the same thing, and you can tell by asking why you want each one:

• You want D even if there will never be a second SMS vendor, because without it you cannot unit test OrderService without sending real messages. D pays off on day one.
• You want O only where new kinds really keep arriving. A tax rule that changes once a year does not need a plugin system.

The difference between dependency inversion and dependency injection (passing things into the constructor, as above) is its own common mix up. It has its own article: dependency inversion vs dependency injection.

When two seem to apply#

In the interview#

Checkpoint#