What are the SOLID principles?

SOLID is an acronym for five object-oriented design principles that promote maintainable, extensible, and understandable code: S — Single Responsibility Principle: a class should have only ONE reason to change. Each class should do one thing well. // Bad: class UserManager handles auth, email, DB, logging // Good: UserAuthenticator, UserEmailSender, UserRepository (separate classes). O — Open/Closed Principle: classes should be OPEN for extension but CLOSED for modification. Add new behavior without changing existing code — use abstraction, polymorphism: // Bad: add new payment type by modifying PaymentProcessor switch statement // Good: PaymentProcessor takes PaymentStrategy; add StripeStrategy without touching PaymentProcessor. L — Liskov Substitution Principle: derived classes must be substitutable for their base classes without altering program correctness. Subclasses must honor the contract of the base: // Bad: Square extends Rectangle but breaks setWidth() behavior (square must keep equal sides) // Good: separate Shape hierarchy, or use composition. I — Interface Segregation Principle: clients should not depend on interfaces they don't use. Prefer small, specific interfaces over fat ones: // Bad: Animal interface with fly(), swim(), walk(), bark() // Good: Flyable, Swimmable, Walkable, Barkable (separate interfaces). D — Dependency Inversion Principle: high-level modules should not depend on low-level modules — both should depend on abstractions. Inject dependencies via interfaces: // Bad: UserService creates new MySQLDatabase() // Good: UserService takes Database interface, inject MySQLDatabase or PostgreSQLDatabase. SOLID principles lead to code that is easier to change, test, and understand.