The SOLID principles, introduced by Robert C. Martin (often called Uncle Bob), are five design guidelines that together promote maintainable, flexible, and testable object-oriented software. The Single Responsibility Principle states that a class should have only one reason to change, meaning it should have just one job or responsibility. A UserService class that handles authentication, email sending, and database queries violates this principle and should be split into separate AuthService, EmailService, and UserRepository classes, each with a clear and focused purpose.
The Open/Closed Principle holds that software entities should be open for extension but closed for modification. New behavior should be added by creating new classes or methods rather than altering existing tested code. Interfaces, abstract classes, and strategy patterns are the typical tools used to enable such extensions without modifying the original code.
The Liskov Substitution Principle requires that objects of a superclass be replaceable with objects of a subclass without breaking the program. A classic violation is modeling a Square class as extending Rectangle, because setting the width on a Square unexpectedly also changes its height. The deeper rule is that subclasses must honor the behavioral contract of the parent class.
The Interface Segregation Principle argues that clients should not be forced to depend on interfaces they do not use. A fat Worker interface that declares work, eat, and sleep methods becomes problematic when a Robot class is forced to implement eating and sleeping methods it does not need. The fix is to split such interfaces into smaller, more focused ones like Workable, Eatable, and Sleepable. Finally, the Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions. In an OrderService, for instance, depending on a PaymentGateway interface rather than a concrete StripePayment class makes it trivial to swap implementations.