SOLID is a set of five object oriented design principles that help programmers write code that is easier to understand, test, change, and reuse. This cheat sheet gives students a quick reference for each principle and the kind of code problem it prevents. It is useful when planning classes, reviewing inheritance, or refactoring a project before it becomes hard to maintain.
The five principles are Single Responsibility, Open Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion. At a high level, SOLID encourages small focused classes, flexible extension, safe inheritance, specific interfaces, and low coupling. The goal is not to use more code, but to make code changes safer and more predictable.
Key Facts
- Single Responsibility Principle: A class should have one main reason to change, meaning it should focus on one job or responsibility.
- Open Closed Principle: Software entities should be open for extension but closed for modification, so new behavior should usually be added without rewriting trusted code.
- Liskov Substitution Principle: If class B is a subtype of class A, then objects of B should work anywhere objects of A are expected without breaking the program.
- Interface Segregation Principle: A class should not be forced to implement methods it does not use, so prefer small specific interfaces over one large general interface.
- Dependency Inversion Principle: High level code should depend on abstractions, not on low level concrete classes.
- A dependency is a class, method, module, or service that another piece of code needs in order to work.
- A good SOLID design reduces coupling and increases cohesion, which makes code easier to test and maintain.
- SOLID principles are guidelines, so the best design depends on the size, purpose, and expected changes of the program.
Vocabulary
- Class
- A class is a blueprint for creating objects that groups related data and behavior.
- Responsibility
- A responsibility is one clear job or reason that a class or module might need to change.
- Abstraction
- An abstraction is a simplified contract, such as an interface or base class, that hides implementation details.
- Coupling
- Coupling describes how strongly one part of a program depends on another part.
- Cohesion
- Cohesion describes how closely the parts of a class or module relate to one focused purpose.
- Interface
- An interface defines methods a class must provide without specifying exactly how those methods are implemented.
Common Mistakes to Avoid
- Putting database, display, and calculation code in one class is a Single Responsibility mistake because one class now has several unrelated reasons to change.
- Editing a working class every time a new feature is added can violate the Open Closed Principle because stable code becomes more likely to break.
- Creating a subclass that removes or weakens expected behavior breaks Liskov Substitution because the subclass cannot safely replace the parent type.
- Making one huge interface with many unrelated methods violates Interface Segregation because classes must implement methods they do not actually need.
- Creating high level logic that directly constructs specific low level classes violates Dependency Inversion because the code becomes harder to replace, test, or reuse.
Practice Questions
- 1 A StudentReport class calculates grades, formats a report, and emails it to parents. Which SOLID principle is most likely being violated, and how could the class be split?
- 2 A program has 4 payment types and the developer edits the same Checkout class each time a new payment type is added. Which principle suggests using a PaymentMethod abstraction instead?
- 3 An interface named Worker has 6 methods, but a RobotWorker class only needs 2 of them and leaves the other 4 empty. Which SOLID principle is violated, and what redesign would help?
- 4 Why can depending on an interface, such as Logger, make a class easier to test than depending directly on a FileLogger class?