OOP organizes code around objects that bundle mutable state with behavior; Functional Programming (FP) organizes code around pure functions and immutable data, treating computation as data transformation. They're different default biases, not opposites — and most modern languages mix both.
| OOP | FP |
|---|
| Unit | Object (state + methods) | Function |
| State | Encapsulated, often mutable | Immutable; avoid side effects |
| Polymorphism | Subtyping / dynamic dispatch | Higher-order functions, generics |
| Adding a type | Easy (new class) | Harder (touch every function) |
| Adding an operation | Harder (touch every class) | Easy (new function) |
That last row is the expression problem: each paradigm makes one axis of change easy and the other hard.
# OOP: data + behavior together, dispatch by type
class Circle:
def __init__(self, r): self.r = r
def area(self): return 3.14159 * self.r ** 2
# FP: data is dumb; behavior is a separate pure function
def area(shape):
match shape:
case ("circle", r): return 3.14159 * r ** 2
case ("square", s): return s * s
OOP → rich domains with identity & lifecycle (orders, sessions, UI widgets)
FP → data pipelines, transformations, concurrency (immutability avoids races)
Modern languages are multi-paradigm (Scala, Kotlin, Python, modern Java/C#), so the practical skill is choosing the right tool per problem, not picking a tribe.
FP's emphasis on immutability and pure functions has reshaped OOP best practices — immutable value objects and dependency injection of behavior are FP ideas now standard in good OO design.