Introduce subclass-specific properties that break functionality when substituting.
// IncorrectIconButton.js
// This button expects an icon and does not handle the absence of one, breaking when used as a BasicButton
const IncorrectIconButton = ({ onClick, icon }) => {
if (!icon) {
throw new Error("Icon is required");
}
return (
<button onClick={onClick}>
<img src={icon} alt="icon" />
</button>
);
};
Interface Segregation Principle (ISP)
No client should be forced to depend on methods it does not use.
Example: Text Component
Do:
Provide specific interfaces for different uses.
// Text.js
const Text = ({ type, children }) => {
switch (type) {
case 'header':
return <h1>{children}</h1>;
case 'title':
return <h2>{children}</h2>;
default:
return <p>{children}</p>;
}
};
Single Responsibility Principle (SRP)
A component should have only one reason to change, meaning it should have only one job.
Example: User Profile Component
Do:
Don’t:
Open/Closed Principle (OCP)
Software entities should be open for extension, but closed for modification.
Example: Themable Button
Do:
Don’t:
Liskov Substitution Principle (LSP)
Objects of a superclass shall be replaceable with objects of its subclasses without breaking the application.
Example: Basic Button and Icon Button
Do:
Don’t:
Interface Segregation Principle (ISP)
No client should be forced to depend on methods it does not use.
Example: Text Component
Do:
Don’t:
Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Example: Data Fetching
Do:
and state management.
Don’t:
Written by Muhammad Talha Waseem
Recent Posts
Recent Posts
🚀 Successfully Integrated Stripe with Java for
Free Tools Every ML Beginner Should Use
Spring Modulith vs Microservices: Understanding the Differences
Archives