What Does SOLID Stand For?
Five short letters, five simple habits, and decades of hard-won wisdom about writing code that does not fall apart the moment it needs to grow. Here is what each letter really means, in plain language.
The Big Idea, in One Breath
Five short letters — S, O, L, I, D — that quietly organise code into sensible, separate compartments, so a change in one place does not ripple out and wreck everything else.
Imagine organising a school backpack. If you toss every pencil, sandwich, textbook, and gym shoe into one giant pocket, finding anything later becomes a nightmare, and one leaking juice box can ruin everything else inside. But if the backpack has sensible, separate compartments — one for books, one for lunch, one for shoes — everything stays easy to find, and a problem in one compartment never spills into the others.
SOLID is a set of five ideas that help programmers organise their code the same thoughtful way — into sensible, separate “compartments” that each do one job well, so that a change or a problem in one part of a program does not ripple out and wreck everything else. The five letters — S, O, L, I, D — each stand for a different principle, and together they form one of the most widely respected sets of guidelines in object-oriented programming.
Think of SOLID like five habits a tidy, thoughtful roommate follows: keep your own stuff in your own space, do not rearrange furniture that is not yours without asking, make sure any substitute roommate can step in without chaos, do not ask everyone to carry keys to rooms they never use, and rely on general house rules rather than one specific person’s quirky habits. None of these habits are complicated on their own — they just require a bit of discipline to follow consistently.
This guide is the fifth in a series exploring the core ideas of object-oriented programming, following earlier guides on the four pillars, inheritance, polymorphism, and abstract classes versus interfaces. SOLID does not introduce any brand-new technical mechanism the way those earlier topics did — instead, it offers hard-won advice on how to actually use those mechanisms wisely, so that the flexibility they offer gets put to genuinely good use rather than wasted or misapplied.
Where SOLID Came From
Not a strict law enforced by any language. A collection of hard-won, practical habits — the kind experienced developers pass on because they have watched codebases go brittle without them.
Each of the five ideas behind SOLID existed on its own for years, developed and written about separately by different thinkers in the software world. The tidy acronym that ties them together — S-O-L-I-D — was popularised later, as a memorable way to group five separate but closely related pieces of wisdom under one umbrella, making them easier to teach, remember, and discuss as a connected set.
It is worth being upfront about something: SOLID is not a strict law enforced by any programming language, and no compiler will refuse to run code that ignores it. It is better understood as a collection of hard-won, practical habits — the kind of advice experienced developers pass on to newer developers, based on real, painful lessons learned from codebases that grew brittle and difficult to change over time.
SOLID is not a set of rules a computer checks for you — it is a set of habits experienced developers recommend because they have personally seen what happens, months or years later, when a codebase ignores them.
Why does that distinction matter? Because it changes how these ideas should actually be applied. A rule enforced by a compiler is binary — either the code satisfies it or the program refuses to run. SOLID is nothing like that. It is closer to advice from an experienced builder who has watched houses built without proper support beams slowly develop cracks over the years. The house does not collapse the day it is built, and nothing stops anyone from skipping the beams — but the consequences show up later, quietly, and are far more expensive to fix after the fact than they would have been to prevent from the start.
SSingle Responsibility Principle
A class should have only one reason to change. Each class should be responsible for one clear job, not several unrelated ones stitched together.
A class should have only one reason to change. In simpler words, each class should be responsible for one clear job, not several unrelated jobs stitched together.
Think of a restaurant where one person is both the head chef and the cash register operator and the person who cleans the bathrooms. Any single change — a new payment system, a new recipe, a new cleaning schedule — disrupts that one overworked person’s entire day. Give each job to a different, focused person instead, and a change to one role barely touches the others.
class Invoice: def calculate_total(self): ... def save_to_database(self): ... def send_email_receipt(self): ...
This single class is quietly responsible for three unrelated concerns: math, data storage, and email. A change to how emails are formatted has no business touching this class at all, yet it would need to. Splitting these into three focused classes — Invoice, InvoiceRepository, and ReceiptMailer — means each one only changes for its own, single reason.
When a class only has one job, it is far easier to understand, test, and safely change. A class juggling five unrelated jobs means five separate reasons someone might need to touch it — and five separate chances to accidentally break something unrelated.
It is worth clarifying what “one responsibility” actually means, since it is easy to misread it as “one method” or “one line of code” — that is not the intent. A class can still have several methods and still respect this principle, as long as every one of those methods genuinely serves the same single, coherent purpose. The Invoice class calculating a subtotal, a tax amount, and a final total are all still part of the one job of “figuring out the math for an invoice” — they do not need to be split apart from each other, only separated from the unrelated jobs of saving to a database or sending an email.
OOpen/Closed Principle
Software entities should be open for extension, but closed for modification. Add new behaviour without reaching in and rewriting code that already works.
Software entities should be open for extension, but closed for modification. In simpler words, it should be possible to add new behaviour without having to reach in and rewrite code that already works.
Think of a power strip with several sockets. When you get a new gadget, you simply plug it into an open socket — you never need to cut open the power strip’s wiring to add support for your new device. The power strip is “closed” against being rewired, but “open” to accepting new things plugged into it.
class Shape: def area(self): pass class Circle(Shape): def area(self): return 3.14159 * self.r ** 2 class Triangle(Shape): # added later, nothing above was touched def area(self): return 0.5 * self.base * self.height
Adding Triangle required zero changes to Shape or Circle. This is only possible because of polymorphism and abstraction, covered in earlier guides in this series — the shared area() promise is what lets new shapes slot in cleanly, without disturbing existing, already-tested code.
“Closed for modification” does not mean a class can never be fixed if it has a genuine bug — it means well-designed extension points should let new behaviour get added without needing to edit stable, already-working code.
This principle becomes especially valuable in larger, shared codebases where several people rely on the same piece of code at once. Every time an existing, already-tested class needs to be edited to support a new case, there is a real risk of accidentally breaking something that was working perfectly well before. By designing classes so that new behaviour can be added alongside them, rather than by cutting into them, the Open/Closed Principle dramatically reduces how often a change in one place accidentally causes a surprise somewhere else entirely.
LLiskov Substitution Principle
Objects of a child class should be usable anywhere an object of the parent class is expected — a test for whether an inheritance relationship is genuinely honest.
Objects of a child class should be usable anywhere an object of the parent class is expected, without breaking anything. Named after computer scientist Barbara Liskov, who first described this idea formally, it is really a test for whether an inheritance relationship is genuinely honest.
Think about a universal phone charger cable. If it truly claims to be “universal,” swapping in any brand of compatible phone should work seamlessly — nobody should discover, after buying it, that certain phones catch fire or simply refuse to charge. If a child class secretly breaks the promises its parent class made, it is like a “universal” charger that quietly only works with some phones.
class Bird: def fly(self): return "Flying!" class Penguin(Bird): def fly(self): raise Exception("Penguins can't fly!") # breaks the promise
Penguin technically extends Bird, but it silently breaks the promise every Bird is supposed to keep — that it can fly. Any code written to work with “any Bird” would crash unexpectedly the moment a real Penguin object showed up. This is exactly what the Liskov Substitution Principle warns against: an inheritance relationship that looks correct on paper but quietly fails to honour its own contract in practice.
This principle is closely tied to the earlier guide on inheritance in this series — it is essentially a formal way of testing whether an “is-a” relationship is genuinely true, or just superficially convenient.
A helpful way to catch this kind of problem before it causes real damage: imagine every place in a program that currently works with the parent type, and ask honestly whether each one would still behave correctly if a specific child object showed up unannounced. If the answer is “well, actually, that one specific child would cause an error there,” that is a strong signal the inheritance relationship needs rethinking — perhaps that particular child should not extend that particular parent at all, or perhaps the parent’s promise needs to be described a little differently so it does not accidentally promise something not every child can honestly deliver.
IInterface Segregation Principle
No class should be forced to depend on abilities it does not actually use. Several small, focused interfaces beat one giant interface demanding everything at once.
No class should be forced to depend on abilities it does not actually use. In simpler words, it is better to offer several small, focused interfaces than one giant interface demanding everything at once.
Think about a job application form that demands you list your driving license, your swimming certification, and your musical instrument skills — even for a job that has nothing to do with any of those. A well-designed form only asks for what is genuinely relevant to that specific job, rather than forcing every applicant to answer questions that do not apply to them.
# Before: one interface forces everyone to implement everything interface Worker: def code(self): ... def cook(self): ... def drive(self): ... # After: small, focused interfaces interface Coder: def code(self): ... interface Cook: def cook(self): ...
A programmer adopting only Coder is never forced to also implement cook(), which they would have no sensible way to fulfil anyway. This directly echoes a point raised in the earlier abstract-class-versus-interface guide in this series: bloated interfaces that bundle unrelated promises together tend to cause more problems than they solve.
It is worth noting how naturally this principle grows out of good, ordinary common sense once it is stated plainly. Nobody would seriously design a job application that demands every applicant list their scuba diving certification, regardless of the actual job. Yet in code, bloated interfaces accumulate gradually and often without anyone consciously deciding to create one — a method gets added “just in case,” then another, until eventually every class adopting that interface is stuck implementing several things it will genuinely never use. Watching for that gradual bloat, and splitting things apart before it becomes unmanageable, is really the whole practical skill behind this principle.
DDependency Inversion Principle
High-level parts of a program should not depend directly on low-level details. Both should depend on a shared abstraction instead.
High-level parts of a program should not depend directly on low-level details — both should depend on a shared abstraction instead. In simpler words, important, big-picture code should not be tightly glued to specific, small, swappable implementation details. This principle rounds out the series nicely, since it directly builds on both the inheritance and the abstract-class-versus-interface guides that came before it — abstractions, in the sense used here, are usually expressed through exactly the kind of interfaces those earlier guides explored in depth.
Think about a standard electrical wall socket. A lamp does not need to be custom-built for one specific power plant’s wiring — it just needs to fit the standard socket shape. The power source behind that socket could be solar, wind, or a generator, and the lamp would never know or care, because both the lamp and the power source agree on one shared, standard interface: the socket.
# Without dependency inversion — tightly glued together class Notifier: def __init__(self): self.emailer = EmailService() # stuck with one specific choice # With dependency inversion — depends on a shared promise class Notifier: def __init__(self, sender: MessageSender): self.sender = sender # any compatible sender works
In the second version, Notifier depends only on the general idea of a MessageSender, not on EmailService specifically. That means an SmsService or a PushNotificationService can be swapped in later without ever touching Notifier‘s own code — directly building on the dependency-related lessons from the earlier abstract-class-and-interface guide in this series.
The word “inversion” in this principle’s name refers to a genuine flip in the usual, natural direction of dependency. Normally, it might feel intuitive for a big, important piece of code to directly depend on a small, specific detail — after all, the big piece is the one that needs the detail to actually do something. Dependency Inversion flips this: instead of the important, high-level code depending directly on a low-level detail, both the high-level code and the low-level detail depend on a shared abstraction sitting between them. The important code no longer cares which specific detail is plugged in underneath, only that it honours the shared promise.
How the Five Work Together
Not five isolated rules. Five habits that support and reinforce each other, and in a well-designed system usually show up together rather than one at a time.
These five principles are not five isolated rules — they support and reinforce each other, and in a genuinely well-designed system, they usually show up together rather than one at a time.
Focused building blocks
Single Responsibility gives you small, focused classes to begin with.
Growth without disruption
Open/Closed lets you extend those focused classes without editing what already works.
Trustworthy substitution
Liskov Substitution ensures the family of related classes can genuinely be swapped safely.
No unnecessary baggage
Interface Segregation keeps each class’s promises lean and relevant.
Flexible connections
Dependency Inversion ties everything together through shared abstractions, not rigid specifics.
Picture a payment processing feature in a real app, and watch how naturally all five principles cooperate. Single Responsibility keeps the “calculate the amount owed” logic separate from the “actually charge the card” logic. Open/Closed lets a new payment method be added as its own class, without editing the checkout flow that already works. Liskov Substitution guarantees that whichever payment method gets used, it behaves as expected, without the checkout code needing special-case handling. Interface Segregation keeps each payment method’s required promises lean — a bank transfer method is not forced to implement a “scan card” action it can never fulfil. And Dependency Inversion means the checkout flow depends only on the general idea of “a payment method,” never on any one specific provider by name. None of these five ideas were applied in isolation — together, they simply describe what a genuinely well-thought-out payment feature tends to look like.
Weighing It Fairly: Pros and Cons
SOLID is not a universally correct answer for every situation. A fair look means being honest about what it costs, as well as what it offers.
SOLID, like every idea in this series, is not a universally correct answer for every situation. A fair look at it means being honest about what it costs, as well as what it offers.
Strengths
- Code becomes easier to test, since each piece has a narrow, focused job.
- New features can often be added without risky changes to existing, working code.
- Bugs tend to stay contained, rather than rippling unpredictably across the system.
- Teams can work on different, well-separated parts with less risk of stepping on each other.
Trade-offs
- Applying every principle strictly, everywhere, can add unnecessary structure to very simple code.
- Splitting things into many small classes and interfaces takes real practice to do well.
- Overzealous abstraction can sometimes make a small system harder to follow, not easier.
Most experienced developers treat SOLID as a set of thoughtful defaults to lean on as a system grows, rather than a strict checklist to satisfy on day one of a tiny, throwaway script.
A useful way to frame the trade-off honestly: SOLID trades a small amount of upfront simplicity for a much larger amount of long-term adaptability. For code that will be thrown away in a week, that trade rarely makes sense. For code that a team expects to maintain, extend, and hand off to new developers for years, that same trade tends to pay for itself many times over.
Common Pitfalls to Avoid
Even developers who understand SOLID well can fall into a handful of well-known traps when applying it in practice.
Treating SOLID as an all-or-nothing checklist
Forcing every single class in a small project to strictly satisfy all five principles from the very first line of code often adds more complexity than the project actually needs. SOLID earns its value most clearly in systems that are genuinely expected to grow and change over time.
Splitting responsibilities so finely that nothing makes sense alone
Single Responsibility can be taken too far, breaking a class into so many tiny fragments that understanding any single piece requires reading through a dozen others. The goal is a sensible, coherent job for each class — not the smallest possible slice imaginable.
Confusing “closed for modification” with “never touch again”
The Open/Closed Principle is about designing good extension points, not freezing code in place forever. A class with a genuine bug still deserves a fix.
Applying dependency inversion without a real reason to swap anything
Introducing an abstraction purely for the sake of following the letter of the principle, when there is genuinely only ever going to be one implementation, adds an extra layer of indirection without any real payoff. This principle earns its value specifically when swapping implementations is a realistic, expected possibility.
Adding abstractions and interfaces “just in case,” without a real, current need driving them. Unused flexibility adds genuine cost — extra files, extra layers, extra things to understand — without delivering any real benefit until that flexibility is actually used.
Where You Will Meet These Every Day
The five habits quietly shape a huge amount of the well-behaved software people rely on daily, even in apps that never mention SOLID anywhere.
SOLID’s five habits quietly shape a huge amount of the well-behaved software people rely on every day, even in apps that never mention “SOLID” anywhere.
| Principle | Everyday Software Example |
|---|---|
| Single Responsibility | A photo app separates its “editing” screen from its “sharing” screen, rather than cramming both into one tangled feature. |
| Open/Closed | A browser can support new extensions without anyone rewriting the browser’s core code for each new one. |
| Liskov Substitution | Any payment method plugged into a checkout flow — card, wallet, bank transfer — works correctly without special-case handling. |
| Interface Segregation | A smart TV remote’s “Volume” buttons do not also demand unrelated settings only a technician would need. |
| Dependency Inversion | A music app can switch its underlying streaming provider without changing how the play button works for the user. |
Principles, one philosophy
Five separate letters, one shared instinct about how healthy code stays healthy.
Roughly when popularised
Individual ideas are older, but the tidy S-O-L-I-D acronym came together during this era.
The ideas travel
SOLID describes structure, not syntax — it applies across virtually every object-oriented language.
It is worth noticing that this same underlying philosophy — small, focused, swappable pieces connected through shared, stable agreements — shows up constantly outside of software too. Standardised shipping containers can be loaded onto any compatible ship, train, or truck, regardless of what is inside them or which company built the vehicle carrying them. Electrical outlets follow a shared regional standard, so any compatible appliance just works, regardless of who manufactured it. SOLID is really software’s version of the same practical wisdom: agree on shared, stable interfaces, keep individual pieces focused, and the whole system stays far easier to grow, repair, and adapt over time.
Questions People Often Ask
Seven honest questions that come up over and over — and honest answers to each.
Do I need to apply all five principles to every project?
Not necessarily, and definitely not all at once from day one. Small, simple projects often do not need the full weight of SOLID. These principles earn their value most clearly as a project grows larger, longer-lived, and more collaborative.
Is SOLID specific to any one programming language?
No. SOLID describes ideas about structure and relationships, not specific syntax, which means it applies across virtually any object-oriented language, even though the exact code that expresses each principle will look slightly different from one language to another.
Which principle is hardest to learn?
Many learners find the Liskov Substitution Principle the trickiest at first, since it requires judging whether an inheritance relationship is genuinely honest, not just superficially convenient — a judgment call that takes practice to develop good instincts for.
How does SOLID relate to the four pillars of OOP covered earlier in this series?
The four pillars describe the basic mechanics object-oriented languages offer — encapsulation, abstraction, inheritance, polymorphism. SOLID builds directly on top of those mechanics, offering guidance on how to use them wisely, rather than introducing brand-new technical tools of its own.
Can following SOLID guarantee bug-free software?
No, and it was never meant to. SOLID is about structure and organisation — how easy code is to understand, test, and safely change — not a guarantee against logical mistakes. A well-structured program can still contain bugs; it is simply much easier to locate and fix them when the structure itself is sound.
Do all five letters carry equal weight in everyday practice?
Not necessarily. Many developers find themselves naturally leaning on Single Responsibility and Dependency Inversion most often in daily work, since those two tend to have the broadest, most immediate impact on how maintainable a codebase feels. The other three matter just as much in the specific situations they are designed for, but come up somewhat less constantly in routine, everyday coding decisions.
Is it a bad sign if a piece of existing code violates SOLID?
Not automatically. Plenty of working, valuable software was written without deliberately following SOLID and still functions perfectly well. Violations become genuinely worth addressing when they start actively causing pain — frequent bugs in one area, difficulty adding new features, or code that nobody feels confident changing. SOLID is best treated as a guide for improvement, not a verdict on whether existing code deserves to exist.
Key Takeaways
Not a rigid law. A set of hard-won habits that help software stay flexible, testable, and welcoming to change as it grows over months and years.
SOLID is not a rigid law — it is a set of hard-won habits that help software stay flexible, testable, and welcoming to change as it grows over months and years. Like any set of habits, the real value comes not from reciting the five letters from memory, but from noticing, again and again in real code, the specific moments where following one of them would genuinely make a difference — and building the instinct to reach for the right one at the right time.
Remember this
- Single Responsibility — give each class one clear job.
- Open/Closed — let new behaviour be added without editing what already works.
- Liskov Substitution — make sure child classes can genuinely stand in for their parents.
- Interface Segregation — keep promises small and relevant, not bloated.
- Dependency Inversion — connect through shared abstractions, not rigid, specific details.
- Applied thoughtfully, not mechanically, these five habits help software stay easy to understand, test, and grow.