SOLID Principles
The SOLID design principles are a set of guidelines in object-oriented programming to make your
code more maintainable, scalable, and flexible. Here’s a simple breakdown of each principle with
examples that you can present in an interview:
1. S - Single Responsibility Principle (SRP)
Definition: A class should have only one reason to change, meaning it should have only one
job or responsibility.
Example:
o Bad: A User class that handles both user data and database operations.
java
Copy code
class User {
String name;
void saveToDatabase() { /* save user to DB */ }
}
o Good: Split the responsibility by creating a separate class for database operations.
java
Copy code
class User {
String name;
}
class UserRepository {
void saveToDatabase(User user) { /* save user to DB */ }
}
2. O - Open/Closed Principle (OCP)
Definition: Software entities (classes, modules, functions) should be open for extension but
closed for modification. You should be able to add new functionality without changing the
existing code.
Example:
o Bad: A Shape class that needs to be modified every time a new shape is added.
java
Copy code
class Shape {
void drawCircle() { /* draw circle */ }
void drawRectangle() { /* draw rectangle */ }
}
o Good: Use inheritance or interfaces to allow adding new shapes without modifying
the Shape class.
java
Copy code
interface Shape {
void draw();
}
class Circle implements Shape {
public void draw() { /* draw circle */ }
}
class Rectangle implements Shape {
public void draw() { /* draw rectangle */ }
}
3. L - Liskov Substitution Principle (LSP)
Definition: Objects of a superclass should be replaceable with objects of a subclass without
affecting the correctness of the program.
Example:
o Bad: A subclass that changes the behavior of its parent in an unexpected way.
java
Copy code
class Bird {
void fly() { /* all birds can fly */ }
}
class Ostrich extends Bird {
void fly() { /* Ostriches can't fly, but the code suggests it can */ }
}
o Good: Use a better design where only flying birds inherit the ability to fly.
java
Copy code
class Bird { /* general bird properties */ }
class FlyingBird extends Bird {
void fly() { /* only flying birds */ }
}
class Ostrich extends Bird { /* Ostrich doesn't fly */ }
4. I - Interface Segregation Principle (ISP)
Definition: A client should not be forced to implement interfaces it does not use. Instead of
one large interface, create smaller, more specific ones.
Example:
o Bad: A Worker interface with methods that all workers don’t need.
java
Copy code
interface Worker {
void work();
void manageTeam();
}
class Engineer implements Worker {
public void work() { /* working */ }
public void manageTeam() { /* irrelevant for engineers */ }
}
o Good: Split into smaller interfaces based on responsibility.
java
Copy code
interface Workable {
void work();
}
interface Manageable {
void manageTeam();
}
class Engineer implements Workable {
public void work() { /* working */ }
}
class Manager implements Workable, Manageable {
public void work() { /* working */ }
public void manageTeam() { /* managing */ }
}
5. D - Dependency Inversion Principle (DIP)
Definition: High-level modules should not depend on low-level modules. Both should
depend on abstractions. Abstractions should not depend on details; details should depend on
abstractions.
Example:
o Bad: A DatabaseService directly dependent on a specific database class like
MySQLDatabase.
java
Copy code
class MySQLDatabase {
void connect() { /* MySQL connection */ }
}
class DatabaseService {
private MySQLDatabase db;
public DatabaseService() {
db = new MySQLDatabase(); // tight coupling
}
void connect() { db.connect(); }
}
o Good: Use interfaces so that high-level modules are not dependent on specific
implementations.
java
Copy code
interface Database {
void connect();
}
class MySQLDatabase implements Database {
public void connect() { /* MySQL connection */ }
}
class PostgreSQLDatabase implements Database {
public void connect() { /* PostgreSQL connection */ }
}
class DatabaseService {
private Database db;
public DatabaseService(Database db) {
this.db = db; // loose coupling
}
void connect() { db.connect(); }
}
How to Present in an Interview:
Start with a brief definition of SOLID as a set of principles to design better, maintainable
software.
Explain each principle in simple terms.
Give small examples like the ones above to show understanding.
Highlight the benefits of each principle, like easier code maintenance, flexibility, and
reduced bugs.
With this explanation, you'll show that you understand how to apply SOLID principles practically in
real-world coding scenarios!
