SOLID Flashcards
What does SOLID stand for?
SOLID is an acronym that stands for five design principles in OOP:
S: Single Responsibility Principle (SRP)
O: Open-Closed Principle (OCP)
L: Liskov Substitution Principle (LSP)
I: Interface Segregation Principle (ISP)
D: Dependency Inversion Principle (DIP)
What is SOLID in object-oriented programming?
Acronym for 5 design principles in OOP:
Single Responsibility Principle (SRP)
Open-Closed Principle (OCP),
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP).
Used to create software systems that are easy to maintain, extend, and modify.
What is the Single Responsibility Principle?
“A class should have only one reason to change.”
Example:
a class that handles user authentication should not also be responsible for sending emails.
What is the Open/Closed Principle?
It states that classes should be
open for extension,
but closed for modification.
Example:
instead of modifying a class to add new functionality, we can create a new class that inherits from the original class and adds the new functionality.
What is the Liskov Substitution Principle?
“Objects of a superclass should be replaceable with objects of its subclasses without breaking the functionality or behavior expected from the superclass.”
Its goal is to ensure that polymorphism is correctly implemented and maintained.
We should consider the following guidelines:
- Method Signatures: Subclasses should respect the method signatures (parameters and return types) defined by the superclass. They should not introduce new parameters or change the expected behavior of the overridden methods.
- Invariant Preservation: Subclasses should maintain the invariants or assumptions established by the superclass. This means they should honor any preconditions (requirements before calling a method) and postconditions (guarantees after a method is executed) defined by the superclass.
- Behavior Preservation: Subclasses should preserve the behavioral contract of the superclass. This means that any assumptions or expectations made by code interacting with the superclass should still hold true when working with its subclasses.
Example:
if we have a class that takes a Shape object as a parameter, we should be able to pass in a Circle or a Square object without causing any issues.
What is the Interface Segregation Principle?
States that a class should not be forced to implement interfaces that it does not need.
Example:
In js and ts, an interface defines a contract specifying the properties and methods an object should have. The ISP suggests that these interfaces should be fine-grained and focused, catering to the needs of individual clients, rather than having bulky and monolithic interfaces.
The benefits:
1. Modularity: Breaking interfaces into smaller, specialized parts allows clients to depend only on the subset of functionality they require. This promotes modularity and avoids imposing unnecessary dependencies.
- Flexibility: Clients are not burdened with unnecessary methods or properties that they don’t need. They can selectively choose interfaces that provide the specific functionality they require, enhancing flexibility in their code.
- Maintenance: When interfaces are segregated, modifications or additions to one part do not affect unrelated clients. This reduces the impact of changes, making maintenance easier and minimizing the chances of introducing bugs.
- Type safety: In TypeScript, segregating interfaces helps enforce stronger type safety. Clients can explicitly depend on specific interfaces, ensuring that the properties and methods they expect are present.
What is the Dependency Inversion Principle?
“High-level modules should not depend on low-level modules, but should depend on abstractions.”
Example:
instead of having a high-level class depend directly on a low-level class, we can create an interface that the low-level class implements and have the high-level class depend on that interface.
What is the benefit of applying the Dependency Inversion Principle?
It allows for more flexible and maintainable code by promoting loose coupling and modularity between modules, which makes it easier to change one module without affecting others.
What is a high-level module and a low-level module? Give examples
high-level module
- encapsulates a larger-scale behavior and is typically composed of many low-level modules.
Example: A service that performs business logic on data retrieved from a database
low-level module
- performs specific, focused tasks and is typically used by higher-level modules.
Example: A database access class that performs CRUD (Create, Read, Update, Delete) operations
What is an abstraction?
It’s a simplified representation of something that hides its complexity and details.
Why should high-level modules depend on abstractions? (SOLID)
Because this allows them to be decoupled from low-level modules, which promotes modularity, testability, and flexibility.
