The Five SOLID Principles, Explained in Under Two Minutes

This video walks through SOLID, the five object-oriented design principles that keep a growing codebase from turning into what the narrator calls spaghetti: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. The framing is practical. As a project grows, changing one thing tends to break three others, and these five rules exist to prevent that.

Each principle gets a short definition plus one concrete animated example, rendered as class diagrams on a dark grid background. The examples are the classic ones (a bloated UserService, a PaymentProcessor with pluggable payment methods, the square-versus-rectangle problem, a do-everything IMachine interface, and a report generator that talks to MySQL through an abstraction), so the video works as both an introduction and a quick refresher.

S: Single Responsibility

A class should do one job and have only one reason to change. The video's example is a UserService that saves user data, sends emails, and writes logs. That is three jobs in one class.

The fix is to split it into three focused classes: a UserRepository with saveUser(), an EmailService with sendEmail(), and a Logger with writeLog(). One class, one job.

O and L: Extend Without Breaking

Open/Closed says code should be open to extension but closed to modification. You should be able to add new features without rewriting old working code. The video shows a PaymentProcessor locked against modification while new payment methods like CreditCard and PayPal plug in from outside.

Liskov Substitution covers the other side of safe extension: any child type must be able to stand in for its parent without breaking things. The example is the classic square-rectangle problem. A Square that extends Rectangle but changes both dimensions when you call setWidth(5) violates the contract. As the video puts it, subtypes must keep their promises.

I and D: Depend on Small Abstractions

Interface Segregation says do not force a class to depend on methods it does not use. The video shows an IMachine interface with print(), scan(), fax(), staple(), and copy(), flagged as a bloated interface. The fix is several small, focused interfaces (IPrinter, IScanner, IFax) so classes take only what they actually need.

Dependency Inversion says high-level code should not depend on low-level details. Both should depend on abstractions. The diagram shows a high-level ReportGenerator depending on an IDatabase interface, which MySQL implements as a low-level detail. Plug into an interface, not a specific implementation, so you can swap parts out without everything collapsing.

The video closes by tying the five letters back together with three payoffs: code that is easier to read, test, and grow.

Key Takeaways

• Single Responsibility: one class, one job, one reason to change. A class that saves users, sends emails, and writes logs should be three classes.
• Open/Closed: add features by extending existing code, not by rewriting working code.
• Liskov Substitution: subtypes must behave like their parent type. A Square that breaks Rectangle's setWidth contract is a violation.
• Interface Segregation: prefer several small interfaces over one bloated one, so classes depend only on methods they use.
• Dependency Inversion: high-level and low-level code should both depend on abstractions, which makes implementations swappable.