Understanding SOLID Design Principles in Coding
Q: What are the principles behind the SOLID design principles? Provide examples where you applied them in your projects.
- Infosys Technical
- Senior level question
Explore all the latest Infosys Technical interview questions and answers
ExploreMost Recent & up-to date
100% Actual interview focused
Create Infosys Technical interview for FREE!
The SOLID design principles are a set of five principles that help create more maintainable, understandable, and flexible software systems. Here’s a breakdown of each principle along with examples from my past projects:
1. S - Single Responsibility Principle (SRP): A class should only have one reason to change, meaning it should only have one job. For instance, in a project where I developed an online bookstore, I created a `Book` class that only handled book details, while another class, `BookRepository`, was responsible for data access operations. This separation allowed us to modify how we handle data without affecting the core book functionalities.
2. O - Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification. In a payment processing system I worked on, I designed an interface `PaymentMethod` with multiple implementations like `CreditCardPayment` and `PayPalPayment`. When a new payment method (e.g., `BitcoinPayment`) was introduced, we simply created a new class that implemented the interface without altering existing code, ensuring stability.
3. L - Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. In a project for a subscription service, I had a class hierarchy for `Subscription`. The `Premium` class inherited from `Basic`, and all methods from `Basic` were properly overridden to maintain their behavior. This allowed us to seamlessly substitute `Basic` with `Premium` in various parts of the system.
4. I - Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. In a microservices architecture, I ensured that each service had its own interface tailored to its needs. For example, instead of a single `UserService` interface with methods for both user management and notification, we created `UserManagementService` and `NotificationService`. This helped reduce dependencies and made it easier to manage changes.
5. D - Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions. In an e-commerce application, instead of a `Cart` class directly depending on a `Product` class, I introduced an interface `IProductService`. The cart only depended on this interface, allowing us to swap different implementations (like a mock or a service that gets products from an external API) without changing the cart logic.
These principles not only improved the structure of my projects but also facilitated better collaboration among team members, as changes could be made with minimal impact on the rest of the system.
1. S - Single Responsibility Principle (SRP): A class should only have one reason to change, meaning it should only have one job. For instance, in a project where I developed an online bookstore, I created a `Book` class that only handled book details, while another class, `BookRepository`, was responsible for data access operations. This separation allowed us to modify how we handle data without affecting the core book functionalities.
2. O - Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification. In a payment processing system I worked on, I designed an interface `PaymentMethod` with multiple implementations like `CreditCardPayment` and `PayPalPayment`. When a new payment method (e.g., `BitcoinPayment`) was introduced, we simply created a new class that implemented the interface without altering existing code, ensuring stability.
3. L - Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. In a project for a subscription service, I had a class hierarchy for `Subscription`. The `Premium` class inherited from `Basic`, and all methods from `Basic` were properly overridden to maintain their behavior. This allowed us to seamlessly substitute `Basic` with `Premium` in various parts of the system.
4. I - Interface Segregation Principle (ISP): Clients should not be forced to depend on interfaces they do not use. In a microservices architecture, I ensured that each service had its own interface tailored to its needs. For example, instead of a single `UserService` interface with methods for both user management and notification, we created `UserManagementService` and `NotificationService`. This helped reduce dependencies and made it easier to manage changes.
5. D - Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules; both should depend on abstractions. In an e-commerce application, instead of a `Cart` class directly depending on a `Product` class, I introduced an interface `IProductService`. The cart only depended on this interface, allowing us to swap different implementations (like a mock or a service that gets products from an external API) without changing the cart logic.
These principles not only improved the structure of my projects but also facilitated better collaboration among team members, as changes could be made with minimal impact on the rest of the system.