What are the benefits of functional programming?

• Immutability means values do not change after creation. Records, LocalDate, and unmodifiable collections are inherently thread-safe because no thread can modify them.
• Pure functions always produce the same output for the same input with no side effects. calculateFee(amount) is trivial to unit-test because it has no hidden dependencies.
• Declarative style describes WHAT to compute (filter.map.reduce) instead of HOW to loop (for/if/accumulator), making code shorter and less error-prone.
• Higher-order functions pass behavior as parameters via lambdas. A TransferService accepts a fee strategy as a Function instead of hard-coding it.
• Easier parallelism comes from immutability and purity: no shared mutable state means parallelStream() can split work across cores safely.
• Java 8 adds FP capabilities alongside OOP. It does not replace OOP.

What is functional programming in Java?

Functional programming (FP) treats computation as the evaluation of mathematical functions. In Java 8+, FP means using lambdas, streams, and functional interfaces to write code that is declarative, immutable, and composable.

What is immutability and why does it matter?

Immutable objects cannot be changed after creation. Java records, String, LocalDate, and BigDecimal are all immutable. This matters for concurrency: an immutable object can be safely shared across threads without synchronization.

package com.bank.model;

import java.math.BigDecimal;

// Immutable record: no setters, all fields final
public record Account(String id, String holder, BigDecimal balance) {}

// Thread-safe by default: no thread can modify an Account
// To "change" the balance, create a new Account
Account updated = new Account(acc.id(), acc.holder(), newBalance);

What are pure functions?

A pure function depends only on its inputs and produces no side effects. It does not modify external state, read from files, or call databases.

// PURE: same input always gives same output
public static BigDecimal calculateInterest(BigDecimal principal, BigDecimal rate) {
    return principal.multiply(rate);
}

// IMPURE: reads external state (database), has side effects (logging)
public BigDecimal calculateInterest(String accountId) {
    Account acc = repository.findById(accountId);  // side effect: DB read
    logger.info("Calculating interest");            // side effect: logging
    return acc.balance().multiply(rate);
}

Pure functions are trivial to test because they have no hidden dependencies.

How is declarative different from imperative?

// IMPERATIVE: describes HOW to compute
BigDecimal total = BigDecimal.ZERO;
for (Account acc : accounts) {
    if (acc.balance().compareTo(BigDecimal.ZERO) > 0) {
        total = total.add(acc.balance());
    }
}

// DECLARATIVE: describes WHAT to compute
BigDecimal total = accounts.stream()
    .map(Account::balance)
    .filter(b -> b.compareTo(BigDecimal.ZERO) > 0)
    .reduce(BigDecimal.ZERO, BigDecimal::add);

The declarative version is shorter, clearer about intent, and less error-prone (no off-by-one, no forgotten initialization).

What are higher-order functions?

A higher-order function takes a function as a parameter or returns one. This is the strategy pattern in one line.

// Higher-order: accepts a fee calculation strategy
public BigDecimal processTransfer(
        BigDecimal amount, Function<BigDecimal, BigDecimal> feeCalculator) {
    BigDecimal fee = feeCalculator.apply(amount);
    return amount.add(fee);
}

// Call with different strategies
processTransfer(amount, a -> a.multiply(new BigDecimal("0.01")));  // 1% fee
processTransfer(amount, a -> new BigDecimal("100"));               // flat Rs.100

How does FP enable easier parallelism?

// Sequential: single thread
BigDecimal seqTotal = accounts.stream()
    .map(Account::balance)
    .reduce(BigDecimal.ZERO, BigDecimal::add);

// Parallel: multiple threads, safe because no shared mutable state
BigDecimal parTotal = accounts.parallelStream()
    .map(Account::balance)
    .reduce(BigDecimal.ZERO, BigDecimal::add);

Because Account is immutable and BigDecimal::add is a pure function, parallelStream can split the work across cores without synchronization.

How is FP different from OOP in Java?

| Aspect | OOP | FP |
|--------|-----|----|
| State | Mutable objects with setters | Immutable values, new copies |
| Behavior | Methods on objects | Functions passed as arguments |
| Control flow | for-loops, if-else | filter, map, reduce |
| Side effects | Common (DB, logging) | Avoided (pure functions) |
| Concurrency | Synchronization needed | Inherently safe (immutable) |

Java 8 combines both: use OOP for domain modeling, FP for data processing pipelines.

What are common mistakes?

WRONG: Using mutable state inside a stream pipeline.

// WRONG: mutating external state inside forEach
List<String> result = new ArrayList<>();
accounts.stream()
    .filter(a -> a.balance().compareTo(MIN) > 0)
    .forEach(a -> result.add(a.holder()));  // side effect!

CORRECT: Use collect instead of forEach with mutation.

// CORRECT: pure pipeline with collect
List<String> result = accounts.stream()
    .filter(a -> a.balance().compareTo(MIN) > 0)
    .map(Account::holder)
    .toList();

What should a senior engineer know?

• The biggest practical win of FP is testability and thread-safety from immutability and purity, not raw syntax brevity.
• In production banking systems, the core domain logic (interest calculation, fee computation) should be pure functions. The impure parts (database reads, API calls) should be at the boundaries.
• Java records (Java 16+) are the idiomatic way to create immutable value objects.
• FP does not mean avoiding all state. It means minimizing mutable shared state and pushing it to the edges of the system.