SOLID Design Pattern in OOP | Kiran | Gurzu

In the last episode of knowledge ketchup at Gurzu, Kiran explored the SOLID principles - five foundational guidelines for writing maintainable and scalable object-oriented code.

Transcript

1. SOLID Design Pattern in OOP Kiran Sharma
2. Gurzu Confidential • Code might work, but over time it becomes hard to maintain or improve. • Hidden Bugs & Undefined Behavior • Security Vulnerabilities • Bug Becomes a Feature • Lack of Test/ Poor Coverage To solve this issue SOLID is one of them. Problem Statements without using proper patterns
3. Gurzu Confidential What is SOLID Principle?
4. Gurzu Confidential • 📅 Introduced in early 2000s • 󰳓 Founded by Robert C. Martin (Uncle Bob) — author of Clean Code and Clean Architecture. Origin of SOLID
5. Gurzu Confidential ✅ Easier to maintain ✅ Test-friendly code ✅ Easier feature additions ✅ Makes teamwork smoother ✅ Keeps your app from becoming a spaghetti mess 🍝 Why SOLID ?
6. Gurzu Confidential 🎯 S — Single Responsibility 🎯 O — Open/Closed 🎯 L — Liskov Substitution 🎯 I — Interface Segregation 🎯 D — Dependency Inversion 📖 A design principle set for building clean, scalable, testable software. What is SOLID?
7. Gurzu Confidential 📌 “A class should have only one reason to change." Bad: class User { void login() { /*...*/ } void sendEmail() { /*...*/ } void saveToDB() { /*...*/ } } Good: class User { void login() { /*...*/ } } class EmailService { void sendEmail() { /*...*/ } } class UserRepository { void saveToDB() { /*...*/ } } 7 S — Single Responsibility Principle
8. Gurzu Confidential 📌 "Software entities should Open for extension, closed for modification." Bad: class PaymentProcessor { void process(String paymentType) { if (paymentType == "Esewa") { ... } else if (paymentType == "Khalti") { ... } // ❌ Needs modification for new types } } Good: abstract class PaymentMethod { // ✅ Extensible via new classes void process(); } class Esewa implements PaymentMethod { ... } class Khalti implements PaymentMethod { ... } 8 Open/Closed principle
9. Gurzu Confidential 9 Liskov Substitution Principle (LSP) 📌 "Subclasses should be substitutable for their parent." Bad: class Bird { void fly() { ... } } class Penguin extends Bird { // ❌ Penguin can't fly! @override void fly() => throw Error(); } Good: abstract class Bird { ... } class FlyingBird extends Bird { void fly() { ... } } // ✅ Proper hierarchy class Penguin extends Bird { ... }
10. Gurzu Confidential 1 0 Interface Segregation Principle (ISP) 📌 "Don’t force clients to depend on unused methods.” Bad: abstract class Worker { void work(); void eat(); // ❌ Not all workers need this } class Robot implements Worker { @override void eat() => throw Error(); // ❌ Forced to implement } Good: abstract class Workable { void work(); } // ✅ Split interfaces abstract class Eatable { void eat(); } class Human implements Workable, Eatable { ... } class Robot implements Workable { ... }
11. Gurzu Confidential 11 Dependency Inversion Principle (DIP) 📌 "Depend on abstractions not concreations” Bad: class UserService { final FirebaseAuth _auth = FirebaseAuth(); // ❌ Hard dependency } Good: class UserService { final AuthInterface _auth; // ✅ Depends on abstraction UserService(this._auth); }
13. “ Gurzu Confidential Thank You!! 13 Kiran Sharma