xxxxxxxxxx
https://www.freecodecamp.org/news/solid-principles-for-programming-and-software-design/
xxxxxxxxxx
Here is an awesome diagram for SOLID principles
https://okso.app/showcase/solid
Source:
https://www.geeksforgeeks.org/solid-principle-in-programming-understand-with-real-life-examples/
1. Single Responsibility Principle: It states that
“a class should have only one reason to change”
which means every class should have a single responsibility
or single job or single purpose.
2. Open/Closed Principle: It states that
“software entities (classes, modules, functions, etc.) should be open for
extension, but closed for modification” which means you should be able to
extend a class behavior, without modifying it.
3. Liskov’s Substitution Principle: According to this principle “Derived or
child classes must be substitutable for their base or parent classes“.
This principle ensures that any class that is the child of a parent class
should be usable in place of its parent without any unexpected behavior.
4. Interface Segregation Principle: It states that “do not force any client
to implement an interface which is irrelevant to them“. Here you should
prefer many client interfaces rather than one general interface and
each interface should have a specific responsibility.
5. Dependency Inversion Principle: High-level modules/classes should not depend
on low-level modules/classes. Both should depend upon abstractions.
Abstractions should not depend upon details.
Details should depend upon abstractions.
xxxxxxxxxx
Single Responsibility Principle (SRP):
This principle states that a class or module should have only one reason to change. In other words, it should have a single responsibility. This helps in keeping your codebase modular and easier to maintain.
Example: Authentication and User Profile
Imagine you're building an authentication and user profile management system for your React app. Instead of cramming all the responsibilities into a single component, let's break them down into separate components:
AuthenticationComponent: Responsible for handling user authentication, login, and registration
function AuthenticationComponent() {
const handleLogin = () => {
// Handle user login logic
};
const handleRegistration = () => {
// Handle user registration logic
};
return (
<div>
{/* Login form */}
{/* Registration form */}
</div>
);
}
UserProfileComponent: Responsible for displaying user profile information and allowing the user to update their profile.
function UserProfileComponent(userProfile) {
const handleUpdateProfile = () => {
// Handle updating user profile logic
};
return (
<div>
{/* Display user profile information */}
{/* Update profile form */}
</div>
);
}
By separating authentication and user profile concerns into different components, you adhere to the Single Responsibility Principle. Each component has a clear and distinct purpose, making the codebase easier to understand, maintain, and extend. This also facilitates reusability – you could potentially use the AuthenticationComponent or UserProfileComponent in other parts of your app without duplicating logic.
Remember, the goal of SRP is to have each component or module focused on one specific task. If you find that a component is trying to do too much or handle multiple concerns, it's a sign that you might want to split it into smaller, more focused components.
Ac