What are SOLID Principles

SOLID is a set of 5 object-oriented design principles that help you write:

• Clean
• Scalable
• Maintainable
• Testable code

S – Single Responsibility
O – Open / Closed
L – Liskov Substitution
I – Interface Segregation
D – Dependency Inversion

1️⃣ S — Single Responsibility Principle (SRP)

A class should have only one reason to change

❌ Bad Example (Flutter)

class UserService {
  void fetchUser() {}
  void saveUserToDB() {}
  void showToast() {}
}

👎 One class doing too many things

✅ Good Example

class UserRepository {
  void fetchUser() {}
}

class DatabaseService {
  void saveUser() {}
}

class UIService {
  void showToast() {}
}

🎯 Flutter Use Case

• Bloc → state management
• Repository → data handling
• Widget → UI only

🧠 Interview one-liner

“SRP ensures each class has a single responsibility, making the code easier to maintain.”

2️⃣ O — Open / Closed Principle (OCP)

Open for extension, closed for modification

❌ Bad Example

double payment(String type) {
  if (type == 'upi') return 100;
  if (type == 'card') return 200;
  return 0;
}

👎 Every new payment requires modifying code

✅ Good Example

abstract class Payment {
  double pay();
}

class UpiPayment implements Payment {
  @override
  double pay() => 100;
}

class CardPayment implements Payment {
  @override
  double pay() => 200;
}

🎯 Flutter Use Case

• Adding new features without touching existing code
• Theming
• Payment gateways
• Auth providers

🧠 Interview one-liner

“OCP allows adding new behavior without modifying existing code.”

3️⃣ L — Liskov Substitution Principle (LSP)

Derived classes must be substitutable for their base classes

❌ Bad Example

class Bird {
  void fly() {}
}

class Penguin extends Bird {
  @override
  void fly() {
    throw Exception("Can't fly");
  }
}

👎 Breaks behavior expectation

✅ Good Example

abstract class Bird {}

abstract class FlyingBird extends Bird {
  void fly();
}

class Sparrow extends FlyingBird {
  @override
  void fly() {}
}

class Penguin extends Bird {}

🎯 Flutter Use Case

• Custom widgets
• Service implementations
• Repositories

🧠 Interview one-liner

“LSP ensures child classes can replace parent classes without breaking functionality.”

4️⃣ I — Interface Segregation Principle (ISP)

Clients should not be forced to implement unused methods

❌ Bad Example

abstract class Worker {
  void work();
  void eat();
}

✅ Good Example

abstract class Workable {
  void work();
}

abstract class Eatable {
  void eat();
}

🎯 Flutter Use Case

• Repository interfaces
• Data sources
• Platform services

🧠 Interview one-liner

“ISP promotes smaller, specific interfaces instead of large general ones.”

5️⃣ D — Dependency Inversion Principle (DIP)

Depend on abstractions, not concrete implementations

❌ Bad Example

class LoginBloc {
  final FirebaseAuth auth = FirebaseAuth.instance;
}

👎 Tightly coupled to Firebase

✅ Good Example

abstract class AuthRepository {
  Future<void> login();
}

class LoginBloc {
  final AuthRepository repository;

  LoginBloc(this.repository);
}

🎯 Flutter Use Case

• Clean Architecture
• Unit testing
• Swapping APIs easily

🧠 Interview one-liner

“High-level modules should depend on abstractions, not concrete implementations.”

SOLID + Clean Architecture (Very Important)

Common Flutter Interview Questions

1. How do you apply SOLID in Flutter?
2. Difference between SRP and Clean Architecture?
3. Why is Dependency Inversion important?
4. How Bloc follows SOLID?
5. Real-world Flutter example of OCP?

One-Screen Summary (Memorize This)

• SRP → One class, one job
• OCP → Extend, don’t modify
• LSP → Child = Parent behavior
• ISP → Small interfaces
• DIP → Depend on abstraction

🔥 Final Tip

SOLID + Clean Architecture + State Management = MNC-ready Flutter developer