SOLID principles ensure clean, maintainable, and scalable code design by encouraging single responsibility, flexible extensibility, proper inheritance, focused interfaces, and dependency on abstractions rather than concrete implementations. These principles help avoid tightly coupled and complex code structures, making systems easier to manage and evolve.
They stand for:
- Single Responsibility: Each module/class should have only one reason to change (one job).
- Open/Closed: Code should be open for extension but closed for modification.
- Liskov Substitution: Subclasses should be replaceable by their base classes without altering the program’s behavior.
- Interface Segregation: Clients should not be forced to depend on interfaces they don’t use.
- Dependency Inversion: High-level modules should rely on abstractions, not on concrete implementations.
The SOLID principles are primarily aligned with OOP concepts, making them easier to explain using C#. However, we can also apply these concepts to our React applications. Therefore, I’ve provided explanations for both together.
1. Single Responsibility Principle (SRP)
- Definition: A class should have one, and only one, reason to change. It should have only one job or responsibility.
C# Example:
// Bad example: Class doing multiple responsibilities
public class InvoiceService
{
public void CreateInvoice() { /* logic for creating invoice */ }
public void PrintInvoice() { /* logic for printing invoice */ }
public void SaveInvoiceToDB() { /* logic for saving invoice to DB */ }
}
// Good example: Separate the responsibilities
public class InvoiceService
{
public void CreateInvoice() { /* logic for creating invoice */ }
}
public class InvoicePrinter
{
public void PrintInvoice() { /* logic for printing invoice */ }
}
public class InvoiceRepository
{
public void SaveInvoiceToDB() { /* logic for saving invoice to DB */ }
}
React Example:
In React, SRP can be applied by ensuring that each component has only one responsibility. If a component is handling multiple concerns, it’s better to break it into smaller, more focused components.
// Bad example: Component doing multiple things
function UserProfile() {
return (
<div>
<UserDetails />
<UserPosts />
<UserNotifications />
</div>
);
}
// Good example: Break it down
function UserProfile() {
return (
<div>
<UserDetails />
<UserPosts />
</div>
);
}
function UserNotifications() {
return <div>Notifications...</div>;
}
2. Open/Closed Principle (OCP)
- Definition: Software entities should be open for extension, but closed for modification.
C# Example:
// Bad example: Modifying the class directly when adding new functionality
public class PaymentService
{
public void ProcessCreditCard() { /* credit card logic */ }
public void ProcessPayPal() { /* PayPal logic */ }
}
// Good example: Extending functionality without modifying existing code
public interface IPayment
{
void ProcessPayment();
}
public class CreditCardPayment : IPayment
{
public void ProcessPayment() { /* credit card logic */ }
}
public class PayPalPayment : IPayment
{
public void ProcessPayment() { /* PayPal logic */ }
}
public class PaymentService
{
public void Process(IPayment paymentMethod)
{
paymentMethod.ProcessPayment();
}
}
React Example:
In React, the Open/Closed Principle can be maintained by composing components and passing props, rather than modifying existing components to support new functionality.
// Bad example: Modifying component directly to add new feature
function Notification({ type }) {
if (type === 'success') return <div>Success!</div>;
if (type === 'error') return <div>Error!</div>;
}
// Good example: Extending behavior via composition
function Notification({ message, Component }) {
return <Component>{message}</Component>;
}
function SuccessComponent({ children }) {
return <div className="success">{children}</div>;
}
function ErrorComponent({ children }) {
return <div className="error">{children}</div>;
}
3. Liskov Substitution Principle (LSP)
- Definition: Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.
C# Example:
// Bad example: Violating Liskov by changing behavior
public class Bird
{
public virtual void Fly() { /* flying logic */ }
}
public class Penguin : Bird
{
public override void Fly() { throw new Exception("Penguins can't fly!"); }
}
// Good example: Use proper inheritance or separate behavior
public class Bird
{
public virtual void Move() { /* logic to move */ }
}
public class Penguin : Bird
{
public override void Move() { /* penguin walking logic */ }
}
React Example:
In React, Liskov Substitution means ensuring that components can be replaced by others without breaking the application. A child component should behave correctly when used in place of its parent.
// Bad example: Replacing ChildA with ChildB causes issues
function Parent({ child }) {
return <div>{child.doSomething()}</div>;
}
function ChildA() {
return <div>Child A</div>;
}
function ChildB() {
return <div>Child B</div>;
}
// Good example: Both ChildA and ChildB are interchangeable
function Parent({ Child }) {
return <Child />;
}
function ChildA() {
return <div>Child A</div>;
}
function ChildB() {
return <div>Child B</div>;
}
4. Interface Segregation Principle (ISP)
- Definition: Clients should not be forced to depend on interfaces they do not use.
C# Example:
// Bad example: A large interface forcing clients to implement methods they don't need
public interface IWorker
{
void Work();
void Eat();
}
public class Robot : IWorker
{
public void Work() { /* work logic */ }
public void Eat() { throw new NotImplementedException(); }
}
// Good example: Split the interface
public interface IWorkable
{
void Work();
}
public interface IFeedable
{
void Eat();
}
public class Robot : IWorkable
{
public void Work() { /* work logic */ }
}
React Example:
In React, ISP can be related to components and props. Components should only receive props they need and not be bloated with unnecessary information.
// Bad example: Passing too many props to the component
function UserProfile({ user, theme, onLogout }) {
return <div>{user.name}</div>;
}
// Good example: Separate concerns, pass only required props
function UserProfile({ user }) {
return <div>{user.name}</div>;
}
function LogoutButton({ onLogout }) {
return <button onClick={onLogout}>Logout</button>;
}
5. Dependency Inversion Principle (DIP)
- Definition: High-level modules should not depend on low-level modules. Both should depend on abstractions (e.g., interfaces in C#).
C# Example:
// Bad example: High-level class depends directly on low-level class
public class FileLogger
{
public void Log(string message) { /* log to file */ }
}
public class Application
{
private FileLogger _logger = new FileLogger();
public void Run() { _logger.Log("Application started"); }
}
// Good example: Depend on an abstraction
public interface ILogger
{
void Log(string message);
}
public class FileLogger : ILogger
{
public void Log(string message) { /* log to file */ }
}
public class Application
{
private ILogger _logger;
public Application(ILogger logger)
{
_logger = logger;
}
public void Run() { _logger.Log("Application started"); }
}
React Example:
In React, DIP can be maintained by passing dependencies through props or context, so components are not tightly coupled to specific implementations.
// Bad example: Component tightly coupled to fetch implementation
function DataFetcher() {
useEffect(() => {
fetch('/api/data').then(response => response.json());
}, []);
}
// Good example: Component depends on abstraction (fetch passed as a prop)
function DataFetcher({ fetchData }) {
useEffect(() => {
fetchData().then(response => response.json());
}, [fetchData]);
}
