Slide 1

Slide 1 text

SOLID Design Pattern in OOP Kiran Sharma

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

Gurzu Confidential What is SOLID Principle?

Slide 4

Slide 4 text

Gurzu Confidential • 📅 Introduced in early 2000s • 󰳓 Founded by Robert C. Martin (Uncle Bob) — author of Clean Code and Clean Architecture. Origin of SOLID

Slide 5

Slide 5 text

Gurzu Confidential ✅ Easier to maintain ✅ Test-friendly code ✅ Easier feature additions ✅ Makes teamwork smoother ✅ Keeps your app from becoming a spaghetti mess 🍝 Why SOLID ?

Slide 6

Slide 6 text

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?

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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 { ... }

Slide 10

Slide 10 text

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 { ... }

Slide 11

Slide 11 text

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); }

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

“ Gurzu Confidential Thank You!! 13 Kiran Sharma