Encapsulation

How encapsulation protects object state, enforces invariants, and makes code maintainable — the OOP principle every senior developer relies on.

public class BankAccount {
    private final String accountNumber;  // immutable
    private final String ownerId;        // immutable
    private BigDecimal balance;
    private boolean frozen;
    private final List<String> transactionLog = new ArrayList<>();
    
    public BankAccount(String accountNumber, String ownerId) {
        this.accountNumber = Objects.requireNonNull(accountNumber);
        this.ownerId = Objects.requireNonNull(ownerId);
        this.balance = BigDecimal.ZERO;
        this.frozen = false;
    }
    
    // Business method — encapsulates deposit logic
    public void deposit(BigDecimal amount) {
        validateNotFrozen();
        if (amount == null || amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Deposit amount must be positive");
        }
        this.balance = this.balance.add(amount);
        log("DEPOSIT", amount);
    }
    
    // Business method — encapsulates withdrawal logic
    public void withdraw(BigDecimal amount) {
        validateNotFrozen();
        if (amount == null || amount.compareTo(BigDecimal.ZERO) <= 0) {
            throw new IllegalArgumentException("Withdrawal amount must be positive");
        }
        if (amount.compareTo(this.balance) > 0) {
            throw new InsufficientFundsException(
                "Insufficient funds. Balance: " + balance + ", Requested: " + amount
            );
        }
        this.balance = this.balance.subtract(amount);
        log("WITHDRAWAL", amount);
    }
    
    // Read-only access to balance
    public BigDecimal getBalance() { return balance; }
    
    // Read-only access to transaction log (defensive copy)
    public List<String> getTransactionLog() {
        return Collections.unmodifiableList(transactionLog);
    }
    
    // No setter for balance — balance can only change via deposit/withdraw
    // No setter for accountNumber or ownerId — they are immutable
    
    public void freeze() { this.frozen = true; }
    public void unfreeze() { this.frozen = false; }
    public boolean isFrozen() { return frozen; }
    
    private void validateNotFrozen() {
        if (frozen) throw new IllegalStateException("Account is frozen");
    }
    
    private void log(String type, BigDecimal amount) {
        transactionLog.add(LocalDateTime.now() + " " + type + ": " + amount);
    }
    
    // Getters for immutable fields
    public String getAccountNumber() { return accountNumber; }
    public String getOwnerId() { return ownerId; }
}

The debate between rich domain models (business logic in entities) and anemic domain models (logic in services) is ongoing. Rich models follow true encapsulation — the Order class knows how to add items, calculate totals, and validate itself. Anemic models put all logic in OrderService. For complex domains, rich models are more maintainable. For simple CRUD apps, anemic models are fine. Choose based on domain complexity.