4 Pillars · SOLID · Design Patterns · Relationships · Interview Gold
A class should have only one reason to change. Do one thing and do it well. Split classes that mix concerns (e.g. User class that also sends email → split into User + EmailService).
Classes should be open for extension, closed for modification. Add new behavior via new classes/interfaces, not by editing existing code. Use inheritance, interfaces, strategy pattern.
Subtypes must be substitutable for their base types without altering correctness. If S extends T, you should be able to use S wherever T is expected. Don't override in ways that break parent's contract.
Clients should not be forced to depend on interfaces they don't use. Split fat interfaces into smaller, specific ones. Many small interfaces > one big interface.
High-level modules should not depend on low-level modules. Both should depend on abstractions (interfaces). Depend on interfaces/abstract classes, not concrete implementations.