FP vs OO, or Why FP?

Introduction

Object-Oriented Programming (OO) has been the dominant paradigm for decades, promising modularity, reusability, and abstraction. Yet, in practice, many OO projects collapse under the weight of tangled dependencies, mutable state, and overengineered hierarchies. Developers often cargo-cult design patterns like Singleton or Factory without grasping their intent, leading to codebases that are rigid, untestable, and resistant to change.

Functional Programming (FP), on the other hand, enforces constraints like immutability and pure functions that naturally guide developers toward modular, testable designs. Languages like Clojure, built on FP principles, make it harder to write bad code by default. This article dissects common OO pitfalls, contrasts them with FP solutions (using Clojure and Java examples), and explains why Domain-Driven Design (DDD) is often misunderstood—even in FP contexts.

---

1. The Allure and Pitfalls of OO Programming

The Problem: OO’s core ideas—encapsulation, inheritance, polymorphism—are powerful but frequently misapplied.

A. Misapplied Inheritance

Explanation: Inheritance is often used for code reuse rather than modeling true “is-a” relationships. This creates fragile hierarchies where changes to base classes break subclasses.

Java Example:

// Bad: Forcing Dog to implement fly() via inheritance
class Animal {
    void eat() {}
    void fly() {} // Not all animals fly!
}
 
class Dog extends Animal {
    @Override
    void fly() {
        throw new UnsupportedOperationException("Dogs can't fly!");
    }
}
 
// Better: Interface segregation
interface Flyable {
    void fly();
}
 
class Bird implements Flyable {
    public void fly() { /* Implementation */ }
}
 
class Dog extends Animal { 
    // No fly() method required
}

Clojure Example:

;; Protocols allow horizontal composition
(defprotocol Flyable (fly [this]))
 
(defrecord Bird [species]
  Flyable
  (fly [this] (str (:species this) " flies!"))

Why FP Wins:
Clojure protocols and Java interfaces both enable composition, but FP discourages inheritance by default. Clojure’s data-centric approach avoids the “method pollution” seen in OO hierarchies.

---

B. Anemic Domain Models

Explanation: Anemic models reduce classes to passive data bags with getters/setters, pushing business logic into procedural “service” classes.

Java Example:

// Bad: Anemic model with external service
class User {
    private String name;
    // Getters/setters only
}
 
class UserService {
    public void updateName(User user, String newName) {
        // No validation
        user.setName(newName);
    }
}
 
// Better: Encapsulate logic in the domain object
class User {
    private String name;
 
    public void updateName(String newName) {
        if (newName == null || newName.isEmpty()) {
            throw new IllegalArgumentException("Invalid name");
        }
        this.name = newName;
    }
}

Clojure Example:

;; Pure functions enforce rules during transformation
(defn update-user [user new-name]
  (validate-name new-name)
  (assoc user :name new-name))

Why FP Wins:
Clojure’s immutable data structures force validation at transformation boundaries. Java’s mutable setters allow invalid states to persist until caught.

---

C. Overengineered Patterns

Explanation: Design patterns like Singleton or Factory are often misused to solve problems that don’t exist.

Java Example:

// Bad: Singleton with global state
class Logger {
    private static Logger instance;
 
    public static Logger getInstance() {
        if (instance == null) {
            instance = new Logger();
        }
        return instance;
    }
}
 
// Better: Dependency injection
class PaymentService {
    private final Logger logger;
 
    public PaymentService(Logger logger) {
        this.logger = logger; // Injected, not global
    }
}

Clojure Example:

;; No need for Singletons - pass dependencies explicitly
(defn log [logger msg] (logger msg))

Why FP Wins:
Clojure functions are stateless by default, making global Singletons unnatural. Java requires discipline to avoid this anti-pattern.

---

2. SOLID Principles: The Gap Between Theory and Practice

The Problem: SOLID principles are often misunderstood in OO due to mutable state and inheritance misuse.

A. Single Responsibility Principle (SRP)

Java Example:

// Bad: Mixing authentication and notifications
class UserManager {
    public void authenticate(User user) { /* ... */ }
    public void sendEmail(User user) { /* ... */ } 
}
 
// Better: Split into two classes
class Authenticator { /* ... */ }
class EmailNotifier { /* ... */ }

Clojure Example:

;; Single-purpose functions
(defn authenticate [user] ...)
(defn send-email [user] ...)

Why FP Wins:
FP decomposes problems into atomic functions, enforcing SRP naturally. OO requires vigilant class design.

---

B. Liskov Substitution Principle (LSP)

Java Example:

// Classic LSP violation: Square-Rectangle problem
class Rectangle {
    void setWidth(int w) { ... }
    void setHeight(int h) { ... }
}
 
class Square extends Rectangle {
    @Override
    void setWidth(int w) {
        super.setWidth(w);
        super.setHeight(w); // Violates rectangle invariants
    }
}

Clojure Example:

;; Data-driven polymorphism avoids hierarchy issues
(defmulti area :type)
(defmethod area :rectangle [r] (* (:width r) (:height r)))
(defmethod area :square [s] (* (:side s) (:side s)))

Why FP Wins:
Clojure’s multimethods dispatch on data attributes, not inheritance trees, making LSP violations impossible.

---

3. Functional Programming: A Path to Better Architecture

The Solution: FP constraints like immutability and pure functions naturally enforce SOLID and modularity.

A. Immutability

Java Example:

// Mutable OO approach
class Cart {
    private List<Item> items = new ArrayList<>();
 
    public void addItem(Item item) {
        items.add(item); // Mutates internal state
    }
}
 
// Immutable FP-like approach in Java
class ImmutableCart {
    private final List<Item> items;
 
    public ImmutableCart(List<Item> items) {
        this.items = List.copyOf(items);
    }
 
    public ImmutableCart addItem(Item item) {
        List<Item> newItems = new ArrayList<>(items);
        newItems.add(item);
        return new ImmutableCart(newItems);
    }
}

Clojure Example:

;; Native immutability
(defn add-item [cart item]
  (update cart :items conj item))

Why FP Wins:
Clojure’s immutability is built-in, while Java requires boilerplate to emulate it.

---

B. Pure Functions

Java Example:

// Impure function with hidden dependency
class ReportGenerator {
    public String generate() {
        Data data = Database.fetch(); // Hidden side effect
        return format(data);
    }
}
 
// Pure function (dependencies explicit)
class ReportGenerator {
    public static String generate(Data data) {
        return format(data); // No side effects
    }
}

Clojure Example:

;; Pure function with explicit inputs
(defn generate-report [data]
  (format-report data))

Why FP Wins:
Clojure makes purity the default, while Java requires discipline to isolate side effects.

---

4. The Role and Misuse of DDD

The Problem: DDD is often reduced to tactical patterns without strategic collaboration.

A. Strategic Design Failures

Java Example:

// Bad: Combined billing/shipping context
class Order {
    private Address shippingAddress;
    private Invoice invoice; // Mixed concerns
}
 
// Better: Separate packages
package com.shipping;
class ShippingOrder { /* ... */ }
 
package com.billing;
class Invoice { /* ... */ }

Clojure Example:

;; Namespaces enforce boundaries
(ns shipping.order (:require [billing.invoice :as invoice]))

Why FP Wins:
Clojure namespaces and Java packages both enforce boundaries, but FP’s data-oriented design reduces coupling.

---

5. Common OO Mistakes to Avoid

A. Fragile Base Classes

Java Example:

// Base class with unstable implementation
class BaseRepository {
    public void save(Object entity) { /* ... */ }
}
 
class UserRepository extends BaseRepository {
    // Depends on parent's save() implementation
}

Clojure Example:

;; Protocol defines contract, not implementation
(defprotocol Repository (save [this entity]))

Why FP Wins:
Protocols decouple interface from implementation, avoiding fragile base classes.

---

Conclusion: Principles Over Paradigms

OO and FP are tools, not religions. The key is understanding why certain patterns work:

• Java’s Strength: Rich ecosystems for GUI apps and enterprise systems.
• Clojure’s Advantage: Concurrency, data pipelines, and correctness-critical systems.
• DDD’s Value: Aligning code with business needs through collaboration.

Final Takeaway:

• Prefer composition over inheritance (in both OO and FP).
• Isolate side effects (Java) or eliminate them (Clojure).
• Let the problem domain dictate architecture, not framework trends.

The best code is the code that survives contact with reality.