SOLID Principles

1️⃣ Single Responsibility Principle (SRP)

🔥 Definition

A class should have only one reason to change.

---

❌ Bad Example

class CreditCardService {
    void processTransaction() { }
    void calculateFees() { }
    void saveTransaction() { }
    void sendNotification() { }
}

---

❌ Why this is BAD

• Multiple responsibilities in one class

• Any change (fee logic, DB, notification) affects same class

• Hard to test (everything tightly coupled)

• High risk of bugs

---

✅ Good Example

class PaymentProcessor {
    void processTransaction() { }
}

class FeeCalculator {
    void calculateFees() { }
}

class TransactionRepository {
    void saveTransaction() { }
}

class NotificationService {
    void sendNotification() { }
}

---

✅ Why this is GOOD

• Each class has single responsibility

• Easy to modify one feature without breaking others

• Easier unit testing

• Cleaner architecture

---

2️⃣ Open/Closed Principle (OCP)

🔥 Definition

Open for extension, closed for modification.

---

❌ Bad Example

class FeeCalculator {
    double calculate(String cardType, double amount) {
        if (cardType.equals("BASIC")) return amount * 0.02;
        if (cardType.equals("PREMIUM")) return amount * 0.01;
        return 0;
    }
}

---

❌ Why this is BAD

• Every new card type requires modifying existing code

• Violates stability (risk of breaking old logic)

• Hard to scale (more if-else chaos)

---

✅ Good Example

interface FeeStrategy {
    double calculate(double amount);
}

class BasicFee implements FeeStrategy {
    public double calculate(double amount) {
        return amount * 0.02;
    }
}

class PremiumFee implements FeeStrategy {
    public double calculate(double amount) {
        return amount * 0.01;
    }
}

---

✅ Why this is GOOD

• New card types added without modifying existing code

• Reduces risk of regression bugs

• Follows plug-and-play design

---

3️⃣ Liskov Substitution Principle (LSP)

🔥 Definition

Subclasses should be replaceable without breaking behavior.

---

❌ Bad Example

abstract class CreditCard {
    abstract void withdrawCash();
}

class RewardsCard extends CreditCard {
    void withdrawCash() {
        throw new RuntimeException("Not supported");
    }
}

---

❌ Why this is BAD

• Subclass breaks expected behavior

• Causes runtime failures

• Not all cards support withdrawal → bad abstraction

---

✅ Good Example

abstract class CreditCard {
    abstract void makePayment(double amount);
}

interface CashWithdrawal {
    void withdrawCash(double amount);
}

class BasicCard extends CreditCard implements CashWithdrawal {
    public void makePayment(double amount) { }
    public void withdrawCash(double amount) { }
}

class RewardsCard extends CreditCard {
    public void makePayment(double amount) { }
}

---

✅ Why this is GOOD

• No unexpected behavior

• Safe substitution of subclasses

• Models real-world constraints correctly

---

4️⃣ Interface Segregation Principle (ISP)

🔥 Definition

Do not force classes to implement methods they don’t use.

---

❌ Bad Example

interface CreditCardService {
    void processPayment();
    void calculateRewards();
    void withdrawCash();
}

---

❌ Why this is BAD

• Classes forced to implement unused methods

• Leads to empty methods or exceptions

• Hard to maintain

---

✅ Good Example

interface PaymentService {
    void processPayment();
}

interface RewardService {
    void calculateRewards();
}

interface CashService {
    void withdrawCash();
}

---

✅ Why this is GOOD

• Only required methods are implemented

• Cleaner and flexible design

• Easier to extend features

---

5️⃣ Dependency Inversion Principle (DIP)

🔥 Definition

Depend on abstractions, not concrete implementations.

---

❌ Bad Example

class CreditCardService {
    private MySQLRepository repo = new MySQLRepository();
}

---

❌ Why this is BAD

• Tight coupling to specific database

• Hard to switch DB or test

• Violates flexibility

---

✅ Good Example

interface TransactionRepository {
    void save(double amount);
}

class CreditCardService {
    private TransactionRepository repo;

    CreditCardService(TransactionRepository repo) {
        this.repo = repo;
    }
}

---

✅ Why this is GOOD

• Loose coupling

• Easy to switch implementations (MySQL → MongoDB)

• Better testability (mocking)