Why do we need encapsulation and abstraction?

package com.bank.core;

import java.math.BigDecimal;

// WRONG: without encapsulation, fields are public
public class BrokenAccount {
    public BigDecimal balance;    // anyone can set this
    public String status;         // anyone can change this
}

// Any code anywhere can do:
// account.balance = new BigDecimal("-999999"); // negative balance: corrupted
// account.status = "SUPERSECRET_ADMIN";       // invalid status: corrupted

// CORRECT: with encapsulation, controlled access
public class Account {
    private BigDecimal balance;
    private String status;

    public void withdraw(BigDecimal amount) {
        if (amount.signum() <= 0) throw new IllegalArgumentException("Amount must be positive");
        if (balance.compareTo(amount) < 0) throw new IllegalStateException("Insufficient funds");
        if (!"ACTIVE".equals(status)) throw new IllegalStateException("Account is frozen");
        balance = balance.subtract(amount);
    }

    public BigDecimal getBalance() { return balance; }
    // No setBalance(): balance can only change through deposit() or withdraw().
}

// Scenario 1: data must always be valid
private BigDecimal balance;  // cannot be negative
private int age;             // cannot be < 0 or > 150
private String email;        // must match regex pattern

// Scenario 2: changes must be tracked or audited
private String status;
public void changeStatus(String newStatus) {
    auditLog.record("Status changed from " + this.status + " to " + newStatus);
    this.status = newStatus;
}

// Scenario 3: changes must trigger side effects
private BigDecimal balance;
public void withdraw(BigDecimal amount) {
    balance = balance.subtract(amount);
    sendSmsNotification(amount);  // side effect on every change
    updateDashboard();             // side effect on every change
}

// Scenario 4: internal representation may change
private long balancePaise;  // stored as paise internally
public BigDecimal getBalance() {
    return BigDecimal.valueOf(balancePaise, 2);  // exposed as rupees
}
// Caller sees BigDecimal. Internal storage is long. Can change without affecting caller.

// WRONG: without abstraction, caller knows all internal steps
public class PaymentController {
    public void handleTransfer(TransferRequest request) {
        Account fromAccount = accountRepo.findById(request.from());
        Account toAccount = accountRepo.findById(request.to());
        if (fromAccount.getBalance().compareTo(request.amount()) < 0)
            throw new IllegalStateException("Insufficient funds");
        fromAccount.withdraw(request.amount());
        toAccount.deposit(request.amount());
        accountRepo.save(fromAccount);
        accountRepo.save(toAccount);
        auditService.logTransfer(fromAccount, toAccount, request.amount());
        notificationService.sendSms(fromAccount.getPhone(), "Debited Rs." + request.amount());
    }
    // 10 lines of implementation details in the controller.
    // If step 5 changes (add compliance check), controller must change.
}

// CORRECT: with abstraction, caller sees one method
public class PaymentController {
    private final PaymentService paymentService;

    public PaymentController(PaymentService paymentService) {
        this.paymentService = paymentService;
    }

    public void handleTransfer(TransferRequest request) {
        paymentService.transfer(request.from(), request.to(), request.amount());
        // One line. Caller does not know the 8 internal steps.
        // Add compliance check: one change in PaymentService, zero changes here.
    }
}

// Scenario 1: complex multi-step process
paymentService.transfer(from, to, amount);  // 8 steps hidden

// Scenario 2: multiple implementations (strategy pattern)
interface InterestCalculator {
    BigDecimal calculate(Account account);
}
class SavingsInterestCalculator implements InterestCalculator { /* ... */ }
class FDInterestCalculator implements InterestCalculator { /* ... */ }
// Caller works with InterestCalculator. Does not know which implementation.

// Scenario 3: implementation may change
interface NotificationService {
    void send(String message);
}
class SmsNotificationService implements NotificationService { /* ... */ }
class EmailNotificationService implements NotificationService { /* ... */ }
// Switch from SMS to Email: caller code unchanged.

// Scenario 4: third-party library wrapper
class MarketDataService {
    public BigDecimal getCurrentPrice(String symbol) {
        // Internally: calls Bloomberg API, handles authentication, retries, caching.
        // Caller sees: one method call.
    }
}

public class PaymentService {
    // Encapsulation: private fields
    private final AccountRepository accountRepo;
    private final AuditService auditService;

    // Abstraction: simple public interface
    public TransferResult transfer(String from, String to, BigDecimal amount) {
        Account fromAccount = accountRepo.findById(from);
        fromAccount.withdraw(amount);  // withdraw validates (encapsulation)
        Account toAccount = accountRepo.findById(to);
        toAccount.deposit(amount);
        auditService.log(from, to, amount);
        return new TransferResult("SUCCESS");
    }
}
// Abstraction hides the HOW. Encapsulation protects the DATA inside.

// WRONG: "making fields private is abstraction"
// CORRECT: making fields private is ENCAPSULATION.
//          Providing a simple public API that hides complex logic is ABSTRACTION.

// WRONG: "interfaces are encapsulation"
// CORRECT: interfaces are ABSTRACTION (hide implementation behind a contract).
//          Encapsulation is about private fields and validated access.