Closures vs Objects: Understanding 'A Poor Man's' Through the Lens of IVP

There is a famous programming koan by Anton van Straaten:

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures."

Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.

On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object."

At that moment, Anton became enlightened.

The koan suggests a symmetry between closures and objects. Does this symmetry hold in practice?

The answer requires examining when each abstraction succeeds and when it becomes a poor substitute for the other. The Independent Variation Principle provides a framework for this analysis.

The Independent Variation Principle (IVP)

I will use the Independent Variation Principle as the analytical framework throughout this article.

The structural definition:

Separate elements governed by different change drivers into distinct units; unify elements governed by the same change driver within a single unit.

The principle addresses two aspects:

• Change drivers are forces that cause code to change: new features, performance requirements, business rules, technical constraints
• Different change drivers indicate elements that vary for independent reasons—these should be separated into distinct units
• Same change driver indicates elements that vary together—these should be unified within a single unit

This dual guidance is what makes the principle actionable. It tells you both when to split things apart and when to keep things together.

For the closures versus objects question, I will identify change drivers for each scenario: behavioral variety (multiple implementations), state evolution (how data changes), resource lifecycle (acquisition and release), dependency timing (when dependencies are provided).

Then I will analyze whether closures or objects better respect the independence of these change drivers.

When an abstraction respects independent change drivers, you get high cohesion (related things stay together), low coupling (unrelated things can change independently), and easy maintenance (changes are localized).

When an abstraction violates independence by coupling things that should vary independently, you get fragility (changes cascade unpredictably), rigidity (hard to adapt to new requirements), and what we call a poor substitute.

This framework transforms the closures versus objects debate from subjective preference into principled analysis.

A Note on Terminology

This article discusses closures versus objects as conceptual abstractions, not closures versus classes specifically. An object is any instance combining state and behavior—whether implemented via classes (Java, C#, TypeScript), prototypes (JavaScript), closures (functional languages, JavaScript factories), or message-passing (Smalltalk, Erlang).

The comparison is not "closures versus classes" but rather: when should you model a problem using closure-thinking (functions capturing context) versus object-thinking (entities with state and methods)? In practice, both are often implemented using similar mechanisms. The key difference is which mental model better respects your change drivers.

The Core Equivalence

First, I should establish that closures and objects are fundamentally equivalent in computational power. You can implement either using the other.

A closure is a function that captures variables from its surrounding lexical scope. These captured variables remain accessible even after the outer function has returned. This mechanism allows functions to carry state without explicit object instantiation.

Object as closure:

// Object approach
class Counter {
  constructor(initial) {
    this.count = initial;
  }

  increment() {
    return ++this.count;
  }

  getCount() {
    return this.count;
  }
}

const counter = new Counter(0);
counter.increment(); // 1
counter.getCount();  // 1

Closure as object:

// Closure approach
function makeCounter(initial) {
  // Variable 'count' is declared in makeCounter's scope
  let count = initial;

  // The returned object contains functions that "close over" count
  return {
    // These arrow functions capture 'count' from the enclosing scope
    // They can access and modify 'count' even after makeCounter returns
    increment: () => ++count,  // Captured: can read and write 'count'
    getCount: () => count      // Captured: can read 'count'
  };
  // When makeCounter returns, 'count' is not destroyed
  // It remains accessible to the returned functions
}

const counter = makeCounter(0);
counter.increment(); // 1 - increments the captured 'count'
counter.getCount();  // 1 - reads the captured 'count'

They look similar. Same interface, same behavior. So what is the difference?

The IVP Lens: Independent Change Drivers

The Independent Variation Principle asks us to identify change drivers—the forces that cause code to change. When we separate elements governed by different change drivers, we achieve high cohesion and low coupling.

The change drivers relevant to data and behavior abstractions:

Change Driver	What Varies	Who Drives It
Behavioral variety	Different implementations of the same interface	Product requirements, feature additions
Data structure	How state is organized and accessed	Performance needs, memory constraints
State evolution	How data changes over time	Business rules, domain logic
Instantiation	How instances are created	Construction complexity, dependency injection
Type relationships	Inheritance, composition, substitutability	Domain modeling, polymorphism needs
Information hiding	What is accessible versus private	API design, encapsulation requirements
Instance quantity	How many instances exist simultaneously	Memory constraints, resource limits
Method lifetimes	How long methods need to exist versus data	Garbage collection, memory management
Dependency timing	When dependencies are provided versus when needed	Testing strategy, staged configuration
State persistence	Need to serialize and transfer state without behavior	Distributed systems, storage requirements
Concurrent access	How multiple threads or processes access state	Concurrency model, immutability needs
Instantiation frequency	How often instances are created versus methods called	Performance optimization, object pooling
Contract enforcement	Compile-time versus runtime checking	Type safety requirements, bug prevention
Testing strategy	Production API versus test doubles	Testability needs, mock complexity

The key insight: closures and classes handle these drivers differently. Neither is universally better—each excels when its strengths align with your change drivers.

When Classes Shine: Explicit Type Hierarchies with Shared Behavior

Consider a graphics rendering system with multiple shape types that share common behavior:

// Using classes - natural fit
abstract class Shape {
  constructor(public color: string) {}

  // Shared behavior across all shapes
  draw(context: CanvasRenderingContext2D) {
    context.fillStyle = this.color;
    this.render(context);
    this.logDrawing();
  }

  protected logDrawing() {
    console.log(`Drew ${this.constructor.name} in ${this.color}`);
  }

  // Each shape implements its own rendering
  protected abstract render(context: CanvasRenderingContext2D): void;

  // Each shape computes its own area
  abstract area(): number;
}

class Circle extends Shape {
  constructor(color: string, private radius: number) {
    super(color);
  }

  protected render(context: CanvasRenderingContext2D) {
    context.beginPath();
    context.arc(0, 0, this.radius, 0, 2 * Math.PI);
    context.fill();
  }

  area() {
    return Math.PI * this.radius ** 2;
  }
}

class Rectangle extends Shape {
  constructor(color: string, private width: number, private height: number) {
    super(color);
  }

  protected render(context: CanvasRenderingContext2D) {
    context.fillRect(0, 0, this.width, this.height);
  }

  area() {
    return this.width * this.height;
  }
}

// Polymorphic usage
function renderShapes(shapes: Shape[], context: CanvasRenderingContext2D) {
  shapes.forEach(shape => shape.draw(context));
}

IVP analysis—what are the change drivers here?

1. Shared behavior driver: Drawing protocol, logging, color management evolve together
2. Variant behavior driver: Each shape has unique rendering and area calculation
3. Type relationship driver: All shapes ARE shapes—substitutability matters
4. Data structure driver: Each shape has unique state (radius versus width and height)

Why classes excel here:

• Shared behavior is reused: The draw() and logDrawing() methods are defined once, inherited by all.
• Type relationships are explicit: The Shape base class documents the contract.
• Variant behavior is enforced: Abstract methods must be implemented.
• Polymorphism is natural: The renderShapes() function works with any Shape subtype.

Can Closures Handle Behavioral Variants?

Absolutely. But the approach is fundamentally different. Closures achieve variants through strategy injection rather than inheritance:

// Closure approach using strategy pattern
function makeShape(color, renderStrategy, areaStrategy) {
  return {
    draw: (context) => {
      context.fillStyle = color;
      renderStrategy(context);
      console.log(`Drew shape in ${color}`);
    },
    area: () => areaStrategy()
  };
}

// Strategies are just functions
const circleRenderer = (radius) => (context) => {
  context.beginPath();
  context.arc(0, 0, radius, 0, 2 * Math.PI);
  context.fill();
};

const circleArea = (radius) => () => Math.PI * radius ** 2;

const rectangleRenderer = (width, height) => (context) => {
  context.fillRect(0, 0, width, height);
};

const rectangleArea = (width, height) => () => width * height;

// Usage
const circle = makeShape('red', circleRenderer(10), circleArea(10));
const rectangle = makeShape('blue', rectangleRenderer(20, 30), rectangleArea(20, 30));

circle.draw(context);  // Works polymorphically

This works. But notice the trade-offs.

What is different with closures:

• No shared behavior inheritance: Each shape gets its own copy of the drawing logic.
• No type relationship enforcement: Nothing ensures strategies are compatible.
• Strategy coordination is manual: Passing radius to both renderer and area calculator requires discipline.
• No "IS-A" relationship: Shapes are not subtypes of anything—just compatible objects.

When closures are better:

• Strategies are first-class: Easy to swap rendering without changing structure.
• Composition over inheritance: Can mix behaviors independently.
• No base class coupling: Changing shared behavior does not force recompilation.

The verdict: classes excel when you have true type hierarchies with shared implementation. Closures excel when you need flexible strategy composition without inheritance coupling.

The choice depends on your change drivers. If you need to evolve shared behavior across types, use classes to avoid duplication. If you need to mix and match strategies independently, use closures to avoid coupling.

When Closures Shine: Stateful Behavior Without Type Hierarchy

Now consider a different scenario: event handlers and callbacks.

// Using closures - natural fit
function setupButton(buttonId) {
  let clickCount = 0;
  let lastClickTime = null;

  const button = document.getElementById(buttonId);

  button.addEventListener('click', () => {
    clickCount++;
    const now = Date.now();

    if (lastClickTime && (now - lastClickTime) < 300) {
      console.log('Double click detected!');
    }

    lastClickTime = now;
    console.log(`Total clicks: ${clickCount}`);
  });

  return {
    reset: () => {
      clickCount = 0;
      lastClickTime = null;
    },
    getCount: () => clickCount
  };
}

const buttonHandler = setupButton('myButton');

IVP analysis—what are the change drivers?

1. State evolution driver: Click count and timing change with user interaction
2. Information hiding driver: Internal state should not leak
3. Instantiation driver: Each button needs its own isolated state

Why closures excel here:

• State encapsulation is automatic: clickCount and lastClickTime are truly private.
• No boilerplate: No class definition, constructor, or this binding.
• Lexical scope is clear: Reading the code reveals exactly what state is captured.
• No type hierarchy needed: This is not a "kind of" anything—it is just stateful behavior.

Attempting This with Classes

// Class approach - awkward
class ButtonHandler {
  constructor(buttonId) {
    this.clickCount = 0;
    this.lastClickTime = null;
    this.button = document.getElementById(buttonId);

    // Need to bind 'this' - common source of bugs
    this.handleClick = this.handleClick.bind(this);
    this.button.addEventListener('click', this.handleClick);
  }

  handleClick() {
    this.clickCount++;
    const now = Date.now();

    if (this.lastClickTime && (now - this.lastClickTime) < 300) {
      console.log('Double click detected!');
    }

    this.lastClickTime = now;
    console.log(`Total clicks: ${this.clickCount}`);
  }

  reset() {
    this.clickCount = 0;
    this.lastClickTime = null;
  }

  getCount() {
    return this.clickCount;
  }
}

const buttonHandler = new ButtonHandler('myButton');

IVP violation—what is wrong here? The class approach has several drawbacks:

• this binding complexity: Must manually bind methods to preserve context.
• False encapsulation: clickCount and lastClickTime are accessible as this.clickCount.
• Unnecessary abstraction: No behavioral variants exist—we do not need inheritance or interfaces.
• Boilerplate overhead: Class definition, constructor, explicit method definitions for single-use code.

The verdict: when you need stateful behavior without type hierarchies or multiple variants, closures are not a "poor man's objects"—they are the right abstraction. Classes here are the poor substitute.

The Deep Difference: What Each Abstraction Separates

Classes: Separating Type from Implementation

Classes excel when you need to separate:

• Interface from implementation: "what" from "how"
• Type hierarchy from concrete types: abstraction from specialization
• Shared behavior from variant behavior: base class from subclasses

// Classic OOP: type hierarchy with shared behavior
abstract class Shape {
  abstract double area();
  abstract double perimeter();

  // Shared behavior
  void describe() {
    System.out.println("Area: " + area());
    System.out.println("Perimeter: " + perimeter());
  }
}

class Circle extends Shape {
  private double radius;

  Circle(double radius) { this.radius = radius; }

  double area() { return Math.PI * radius * radius; }
  double perimeter() { return 2 * Math.PI * radius; }
}

class Rectangle extends Shape {
  private double width, height;

  Rectangle(double width, double height) {
    this.width = width;
    this.height = height;
  }

  double area() { return width * height; }
  double perimeter() { return 2 * (width + height); }
}

Change drivers aligned:

• Adding new shapes: Add new subclasses without modifying existing ones
• Changing shared behavior: Modify base class without touching subclasses
• Polymorphic operations: Work with Shape interface regardless of concrete type

This is the Open-Closed Principle in action—and it is natural with classes.

Closures: Separating Behavior from State Capture

Closures excel when you need to separate:

• Stateful behavior from state management: The closure "remembers" without explicit state objects
• Lexical scope from execution scope: What variables exist when defined versus when called
• Configuration from execution: Captured context configures behavior

// Classic closure: behavior configured by captured context
function makeRateLimiter(maxRequests, timeWindow) {
  let requests = [];

  return function(action) {
    const now = Date.now();

    // Remove old requests outside time window
    requests = requests.filter(time => (now - time) < timeWindow);

    if (requests.length >= maxRequests) {
      throw new Error('Rate limit exceeded');
    }

    requests.push(now);
    return action();
  };
}

// Each rate limiter has its own isolated state
const apiLimiter = makeRateLimiter(100, 60000);  // 100 requests per minute
const authLimiter = makeRateLimiter(5, 60000);   // 5 requests per minute

apiLimiter(() => callApi());
authLimiter(() => authenticate());

Change drivers aligned:

• Changing rate limits: Create new limiters with different parameters
• Adding rate limiting: Wrap any function without modifying its code
• Independent state: Each limiter's state is isolated via closure

This is the Strategy Pattern without the ceremony—and it is natural with closures.

When Classes Are "A Poor Man's Closures"

Classes become a poor substitute for closures when:

1. You Are Forcing Type Hierarchy Where None Exists

// Poor man's closure using a class
class Logger {
  constructor(prefix) {
    this.prefix = prefix;
  }

  log(message) {
    console.log(`${this.prefix}: ${message}`);
  }
}

const logger = new Logger('[INFO]');
logger.log('Something happened');

// Much simpler with a closure
function makeLogger(prefix) {
  return (message) => console.log(`${prefix}: ${message}`);
}

const logger = makeLogger('[INFO]');
logger('Something happened');

Change drivers:

• Configuration (prefix) versus Execution (logging messages)
• No behavioral variety, no type hierarchy needed

IVP insight: there is no behavioral variety here. No subclasses. No polymorphism. The class adds ceremony without benefit.

2. You Are Creating Single-Method Classes

// Poor man's closure using a class
class Validator {
  constructor(minLength, maxLength) {
    this.minLength = minLength;
    this.maxLength = maxLength;
  }

  validate(input) {
    return input.length >= this.minLength &&
           input.length <= this.maxLength;
  }
}

const validator = new Validator(5, 20);
validator.validate('hello');

// Much simpler with a closure
function makeValidator(minLength, maxLength) {
  return (input) =>
    input.length >= minLength &&
    input.length <= maxLength;
}

const validator = makeValidator(5, 20);
validator('hello');

Change drivers:

• Configuration (min, max) versus Validation (checking input)
• Single responsibility: just one operation

IVP insight: a class with one method is just a function. The class wrapper obscures this simplicity.

3. You Are Using "This" to Smuggle State

// Poor man's closure using a class
class Accumulator {
  constructor() {
    this.total = 0;
  }

  add(value) {
    this.total += value;
    return this.total;
  }
}

// Simpler with a closure
function makeAccumulator() {
  let total = 0;
  return (value) => total += value;
}

Change drivers:

• State (total) exists only to be captured by behavior (accumulation)
• No type hierarchy or multiple methods needed

IVP insight: when state exists solely to be captured by methods, closures make this relationship explicit.

When Closures Are "A Poor Man's Objects"

Closures become a poor substitute for classes when:

1. You Are Faking Methods as Properties

// Poor man's object using closures
function makePerson(name, age) {
  return {
    getName: () => name,
    getAge: () => age,
    haveBirthday: () => { age++; },
    introduce: () => `Hi, I'm ${name}, ${age} years old`
  };
}

// More honest with a class
class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }

  haveBirthday() {
    this.age++;
  }

  introduce() {
    return `Hi, I'm ${this.name}, ${this.age} years old`;
  }
}

Change drivers:

• Multiple methods operating on shared state
• Object cohesion: behaviors belong together

IVP insight: when you are returning an object with multiple methods that all operate on the same state, you are already thinking in objects—just admit it.

2. You Are Implementing Ad-Hoc Polymorphism

// Poor man's polymorphism using closures
function makeAnimal(type, sound) {
  return {
    speak: () => console.log(sound),
    getType: () => type
  };
}

const dog = makeAnimal('dog', 'woof');
const cat = makeAnimal('cat', 'meow');

// More explicit with classes
class Animal {
  speak() { throw new Error("Must implement"); }
}

class Dog extends Animal {
  speak() { console.log('woof'); }
}

class Cat extends Animal {
  speak() { console.log('meow'); }
}

const dog = new Dog();
const cat = new Cat();

function makeAnimalSpeak(animal) {
  animal.speak();  // Polymorphism enforced by type system
}

Change drivers:

• Behavioral variants (dog, cat) of same interface (Animal)
• Type hierarchy with polymorphic substitution

IVP insight: when you have multiple variants of the same interface and need polymorphic substitution, classes make the type relationships explicit.

3. You Are Manually Managing Shared State

// Poor man's shared state using closures
function makeSharedCounter() {
  let count = 0;

  return {
    instance1: {
      increment: () => ++count,
      get: () => count
    },
    instance2: {
      increment: () => ++count,
      get: () => count
    }
  };
}

// More natural with a class
class Counter {
  static count = 0;

  increment() {
    return ++Counter.count;
  }

  get() {
    return Counter.count;
  }
}

const counter1 = new Counter();
const counter2 = new Counter();
counter1.increment(); // Both see the same count
counter2.get();

Change drivers:

• Shared state across multiple instances
• Instance-specific behavior accessing shared data

IVP insight: when you need shared state across instances, classes have explicit mechanisms (static properties). Closures require manual wiring.

The Fundamental Pattern: Aligning Abstraction to Change Drivers

The Independent Variation Principle reveals the deep pattern.

Use classes when you have:

• Behavioral variety with type relationships: Multiple implementations of the same interface
• Polymorphic substitution: Different types used interchangeably
• Shared behavior via inheritance: Base class provides common functionality
• Explicit type hierarchy: "Is-a" relationships matter for the domain
• Multiple methods operating on shared state: The object represents a cohesive entity

Example domains: payment systems, shape hierarchies, UI components, domain entities.

Use closures when you have:

• Stateful behavior without type hierarchy: Just behavior plus private state
• Configuration via capture: Lexical scope parameterizes behavior
• Single-purpose functions: One operation, possibly with private state
• Callback and event handlers: Behavior tied to specific context
• Information hiding without boilerplate: True privacy via lexical scope

Example domains: event handlers, rate limiters, memoization, loggers, validators.

The Hybrid Approach: Interfaces and Closures

Modern languages often combine both:

// TypeScript: Interface + Closure
interface PaymentProcessor {
  process(amount: number): PaymentResult;
}

function makeCreditCardProcessor(cardNumber: string): PaymentProcessor {
  // Closure captures card details
  return {
    process: (amount) => ({
      method: 'credit',
      amount,
      card: cardNumber
    })
  };
}

function makePayPalProcessor(email: string): PaymentProcessor {
  return {
    process: (amount) => ({
      method: 'paypal',
      amount,
      email
    })
  };
}

// Polymorphic use with type safety
function executePayment(processor: PaymentProcessor, amount: number) {
  return processor.process(amount);
}

executePayment(makeCreditCardProcessor('1234'), 100);
executePayment(makePayPalProcessor('[e-mail]'), 100);

This combines the strengths of both approaches. The interface provides compile-time type safety. The closures provide implementation simplicity. No inheritance hierarchy needed.

Constructor Injection and Partial Application: The Deep Equivalence

I have come to realize that constructor injection and partial application are fundamentally the same pattern expressed in different abstractions. Both separate dependency configuration from data processing.

Constructor injection (classes):

// Java: Constructor injection
class PaymentService {
    private final Logger logger;
    private final Database db;

    public PaymentService(Logger logger, Database db) {
        this.logger = logger;  // Dependencies provided upfront
        this.db = db;
    }

    public PaymentResult process(PaymentRequest request) {
        logger.log("Processing payment");
        return db.save(request);  // Use captured dependencies
    }
}

// Usage: dependencies provided at construction
PaymentService service = new PaymentService(logger, db);
service.process(request1);
service.process(request2);

Partial application (closures):

// JavaScript: Partial application
function makePaymentService(logger, db) {  // Dependencies provided upfront
  return function process(request) {
    logger.log("Processing payment");
    return db.save(request);  // Use captured dependencies
  };
}

// Usage: dependencies provided at factory call
const service = makePaymentService(logger, db);
service(request1);
service(request2);

The structural similarity is striking. Both separate "things that change slowly" (dependencies) from "things that change often" (data to process).

Change drivers:

1. Dependency configuration: Logger and database connection change rarely
2. Data processing: Payment requests change frequently

These vary independently—you might process thousands of payments with the same logger and database.

Both approaches respect this independence by separating configuration (provide dependencies once) from execution (process many requests).

The difference is syntactic, not semantic:

• Constructor injection uses language constructs (constructors, fields, this)
• Partial application uses function composition (factory functions, closure capture)

When dependencies come all-at-once, both work equally well. The choice depends on language idioms and whether you need other object-oriented features (inheritance, interfaces, multiple methods).

Staged Configuration: Where Closures Truly Excel

But closures reveal their power when dependencies do not come all-at-once. When you need staged configuration, closures handle this naturally through nested function calls.

Consider a database query builder that needs configuration in stages:

// JavaScript: Multi-stage configuration via nested closures
function query(table) {
  return {
    where: (condition) => ({
      orderBy: (field) => ({
        limit: (n) => ({
          execute: () => {
            // All parameters captured via closure chain
            return db.execute(`SELECT * FROM ${table} WHERE ${condition} ORDER BY ${field} LIMIT ${n}`);
          }
        })
      })
    })
  };
}

// Usage: staged configuration
const results = query('users')
  .where('age > 18')
  .orderBy('name')
  .limit(10)
  .execute();

Each stage captures its parameters, building up the closure's captured environment. This is partial application taken to its logical conclusion.

Attempting this with classes requires builder pattern boilerplate:

// Java: Builder pattern for staged configuration
class QueryBuilder {
    private String table;
    private String condition;
    private String orderByField;
    private Integer limit;

    public QueryBuilder(String table) {
        this.table = table;
    }

    public QueryBuilder where(String condition) {
        this.condition = condition;
        return this;
    }

    public QueryBuilder orderBy(String field) {
        this.orderByField = field;
        return this;
    }

    public QueryBuilder limit(int n) {
        this.limit = n;
        return this;
    }

    public ResultSet execute() {
        return db.execute("SELECT * FROM " + table + " WHERE " + condition +
                         " ORDER BY " + orderByField + " LIMIT " + limit);
    }
}

// Usage: same staged configuration
ResultSet results = new QueryBuilder("users")
    .where("age > 18")
    .orderBy("name")
    .limit(10)
    .execute();

This works, but notice the overhead. The class requires explicit field declarations, assignments in each method, and manual return of this. The closure version achieves the same result through nested function returns.

IVP insight: when dependency timing and usage timing vary independently—when you need to provide dependencies in stages rather than all-at-once—closures respect this independence more naturally than constructor injection. Partial application is the natural expression of staged configuration.

Construction and Destruction: Lifecycle Management

Construction: Ensuring Valid Instances

Both classes and closures can enforce invariants at construction, ensuring no invalid instances exist.

Classes with constructors:

// Java: Constructor validates invariants
class PaymentRequest {
    private final String cardNumber;
    private final String cvv;
    private final int amount;
    private final String currency;

    public PaymentRequest(String cardNumber, String cvv, int amount, String currency) {
        // Validation at construction
        if (cardNumber == null || cardNumber.length() != 16) {
            throw new IllegalArgumentException("Invalid card number");
        }
        if (cvv == null || cvv.length() != 3) {
            throw new IllegalArgumentException("Invalid CVV");
        }
        if (amount <= 0) {
            throw new IllegalArgumentException("Amount must be positive");
        }
        if (currency == null) {
            throw new IllegalArgumentException("Currency required");
        }
        // Cross-field validation
        if ("USD".equals(currency) && amount > 10000) {
            throw new IllegalArgumentException("USD transactions limited to $10,000");
        }

        this.cardNumber = cardNumber;
        this.cvv = cvv;
        this.amount = amount;
        this.currency = currency;
    }

    // If this object exists, it's valid
}

Closures with factory functions:

// JavaScript: Factory validates invariants
function makePaymentRequest(cardNumber, cvv, amount, currency) {
    // All validation upfront
    if (!cardNumber || cardNumber.length !== 16) {
        throw new Error("Invalid card number");
    }
    if (!cvv || cvv.length !== 3) {
        throw new Error("Invalid CVV");
    }
    if (amount <= 0) {
        throw new Error("Amount must be positive");
    }
    if (!currency) {
        throw new Error("Currency required");
    }
    if (currency === "USD" && amount > 10000) {
        throw new Error("USD transactions limited to $10,000");
    }

    return {
        getCardNumber: () => cardNumber,
        getCVV: () => cvv,
        getAmount: () => amount,
        getCurrency: () => currency,
        submit: () => { /* submit logic */ }
    };
}

The fundamental similarity: both enforce "no invalid instances"—you cannot get a reference to an invalid object or closure. The difference is in how construction complexity is expressed. Objects use language constructs (constructors, builders, access modifiers). Closures use function composition (staged factories, validation functions).

One key difference: with classes, you can have partially constructed objects during constructor execution (before all fields initialized). With closures, the closure only exists after the factory returns—no "partial closure" state. This makes closures slightly safer: no "this-escape" problem where this reference leaks during construction.

Destruction: Resource Cleanup

Just as construction differs between objects and closures, so does destruction and resource cleanup.

Change drivers:

1. Resource acquisition: When resources (files, sockets, memory) are obtained
2. Resource release: When resources must be cleaned up
3. Lifecycle management: How to ensure cleanup happens reliably

These vary independently—you might acquire resources at construction but need to release them at different times (immediately after use, after a delay, when the program exits).

Objects provide explicit cleanup mechanisms:

// Java: try-with-resources (AutoCloseable interface)
class FileProcessor implements AutoCloseable {
    private final FileInputStream file;
    private final BufferedReader reader;

    public FileProcessor(String path) throws IOException {
        this.file = new FileInputStream(path);
        this.reader = new BufferedReader(new InputStreamReader(file));
    }

    public String readLine() throws IOException {
        return reader.readLine();
    }

    // Cleanup method - called automatically by try-with-resources
    @Override
    public void close() throws IOException {
        reader.close();  // Close reader first
        file.close();    // Then close file
        System.out.println("Resources cleaned up");
    }
}

// Usage: cleanup happens automatically
try (FileProcessor processor = new FileProcessor("data.txt")) {
    String line = processor.readLine();
    // Use the file...
}  // close() called automatically here, even if exception thrown

Closures rely on language garbage collection or explicit cleanup functions:

// JavaScript: Explicit cleanup function
function makeFileProcessor(path) {
    const file = fs.openSync(path, 'r');
    let closed = false;

    return {
        readLine: () => {
            if (closed) throw new Error('File already closed');
            return fs.readFileSync(file, 'utf8').split('\n')[0];
        },
        close: () => {
            if (!closed) {
                fs.closeSync(file);
                closed = true;
                console.log('Resources cleaned up');
            }
        }
    };
}

// Usage: manual cleanup (no automatic try-with-resources)
const processor = makeFileProcessor('data.txt');
try {
    const line = processor.readLine();
    // Use the file...
} finally {
    processor.close();  // Must remember to call this
}

IVP insight: when resource acquisition and resource release vary independently, explicit cleanup mechanisms (destructors, disposable pattern, try-with-resources) help ensure resources are released even when exceptions occur. Classes have language support for this (AutoCloseable in Java, IDisposable in C#, destructors in C++). Closures require manual discipline or language-level support (defer in Go, RAII via scope guards).

For resource management, classes with explicit lifecycle methods generally provide better guarantees than closures, because the language can enforce cleanup patterns (try-with-resources, using statements).

Contract Enforcement: Compile-Time versus Runtime

Nominal Interfaces: Compile-Time Safety

In statically-typed languages with nominal type systems, interfaces provide compile-time contract enforcement:

// Java: Interface contract enforced at compile-time
interface PaymentProcessor {
    PaymentResult process(int amount);
    String getMethodName();
}

class CreditCardProcessor implements PaymentProcessor {
    private String cardNumber;

    public CreditCardProcessor(String cardNumber) {
        this.cardNumber = cardNumber;
    }

    public PaymentResult process(int amount) {
        return new PaymentResult("credit", amount, cardNumber);
    }

    public String getMethodName() {
        return "Credit Card";
    }
}

// This won't compile - missing getMethodName()
class BrokenProcessor implements PaymentProcessor {
    public PaymentResult process(int amount) {
        return new PaymentResult("broken", amount, null);
    }
    // ERROR: BrokenProcessor is not abstract and does not override getMethodName()
}

Closures in statically-typed functional languages use structural typing or module signatures:

// TypeScript: Structural typing (duck typing with compile-time checking)
interface PaymentProcessor {
  process(amount: number): PaymentResult;
  getMethodName(): string;
}

function makeCreditCardProcessor(cardNumber: string): PaymentProcessor {
  return {
    process: (amount) => ({ method: 'credit', amount, card: cardNumber }),
    getMethodName: () => 'Credit Card'
  };
}

// This won't compile - missing getMethodName()
function makeBrokenProcessor(): PaymentProcessor {
  return {
    process: (amount) => ({ method: 'broken', amount, card: null })
    // ERROR: Type '{ process: ... }' is not assignable to type 'PaymentProcessor'
    // Property 'getMethodName' is missing
  };
}

TypeScript provides structural typing: if the object has the right shape (properties and methods), it satisfies the interface. No explicit implements declaration needed. But the compiler still catches violations at compile-time.

For most production code, compiler-enforced contracts provide significant advantages:

• Fail fast: Errors caught at compile-time, not runtime
• Refactoring safety: Changing an interface breaks all non-compliant implementations immediately
• Documentation: The interface is the contract—no ambiguity
• Tooling support: IDEs provide autocomplete, refactoring, navigation
• Team coordination: Explicit contracts prevent misunderstandings
• Maintenance: Easy to see all implementations of an interface

Runtime Contract Enforcement in Dynamic Languages

In dynamic languages like JavaScript (without TypeScript) or Python, there is no compile-time checking. If you want to enforce contracts, you must do it at runtime—it is not optional, it is the only way to catch contract violations.

Without runtime validation, contract violations fail silently or cause cryptic errors later:

// JavaScript: No compile-time checking means silent failures
function executePayment(processor, amount) {
    return processor.process(amount);  // What if processor.process doesn't exist?
}

const brokenProcessor = {
    // Missing process() method!
    getMethodName: () => 'Broken'
};

// This fails at RUNTIME when process() is called
executePayment(brokenProcessor, 100);  // TypeError: processor.process is not a function
// Error happens LATE - deep in execution, hard to debug

The problem: the error happens far from where the broken object was created. You only discover the contract violation when you try to call the missing method.

The solution: runtime validation catches violations early, at construction time. Both objects and closures can enforce this:

// JavaScript: Runtime contract validation for objects
class PaymentProcessor {
    constructor(implementation) {
        // Validate interface at construction time
        if (typeof implementation.process !== 'function') {
            throw new TypeError('PaymentProcessor must have process() method');
        }
        if (typeof implementation.getMethodName !== 'function') {
            throw new TypeError('PaymentProcessor must have getMethodName() method');
        }

        this.implementation = implementation;
    }

    process(amount) {
        return this.implementation.process(amount);
    }

    getMethodName() {
        return this.implementation.getMethodName();
    }
}

// Usage: validation happens at construction
const validImpl = {
    process: (amount) => ({ success: true, amount }),
    getMethodName: () => 'Credit Card'
};

const processor = new PaymentProcessor(validImpl);  // OK

const invalidImpl = {
    process: (amount) => ({ success: true, amount })
    // Missing getMethodName!
};

const badProcessor = new PaymentProcessor(invalidImpl);  // Throws TypeError immediately

With closures, you can do the same validation in factory functions:

// JavaScript: Runtime contract validation for closures
function makePaymentProcessor(implementation) {
    // Validate interface before creating closure
    if (typeof implementation.process !== 'function') {
        throw new TypeError('Implementation must have process() method');
    }
    if (typeof implementation.getMethodName !== 'function') {
        throw new TypeError('Implementation must have getMethodName() method');
    }

    // Return closure that delegates to validated implementation
    return {
        process: (amount) => implementation.process(amount),
        getMethodName: () => implementation.getMethodName()
    };
}

// Usage: same validation
const processor = makePaymentProcessor(validImpl);  // OK
const badProcessor = makePaymentProcessor(invalidImpl);  // Throws TypeError

More sophisticated runtime validation uses proxy objects in JavaScript:

// JavaScript: Proxy-based contract enforcement
function createContractProxy(obj, contract) {
    return new Proxy(obj, {
        get(target, prop) {
            if (!(prop in target)) {
                throw new Error(`Contract violation: missing property '${prop}'`);
            }
            if (typeof contract[prop] === 'function' && typeof target[prop] !== 'function') {
                throw new Error(`Contract violation: '${prop}' must be a function`);
            }
            return target[prop];
        }
    });
}

// Define contract
const paymentProcessorContract = {
    process: Function,
    getMethodName: Function
};

// Wrap implementation with contract checking
const processor = createContractProxy(
    { process: (x) => x },
    paymentProcessorContract
);

processor.process(100);  // OK
processor.getMethodName();  // ERROR: Contract violation: missing property 'getMethodName'

Python has similar runtime contract enforcement through protocols (PEP 544) and type checking libraries.

IVP insight: the choice is not about computational power—both approaches are Turing-complete. It is about which change drivers matter:

• Safety and maintainability drive changes: Use compiler-enforced contracts (nominal interfaces)
• Flexibility and rapid iteration drive changes: Structural typing may suffice

For production systems, especially in teams, the safety and tooling benefits of compiler-enforced contracts usually outweigh the flexibility of structural typing. TypeScript's popularity shows this: developers wanted JavaScript's flexibility with compile-time safety.

Memory and Performance Considerations

Memory: Shared Methods versus Per-Instance Functions

Change drivers:

1. Instance quantity: How many instances you create
2. Method complexity: How much code each method contains

These vary independently—you might create thousands of simple instances or a few complex ones.

Classes share methods via prototype chain:

// JavaScript: Class methods shared via prototype
class Calculator {
    add(a, b) { return a + b; }
    subtract(a, b) { return a - b; }
    multiply(a, b) { return a * b; }
}

// Creating 1000 instances
const calculators = Array.from({ length: 1000 }, () => new Calculator());

// Memory: 1000 instances + 1 shared prototype with 3 methods
// Each instance: ~small overhead (just prototype reference)
// Methods: defined once, shared by all

Closures create methods per instance:

// JavaScript: Closure methods created per instance
function makeCalculator() {
    return {
        add: (a, b) => a + b,
        subtract: (a, b) => a - b,
        multiply: (a, b) => a * b
    };
}

// Creating 1000 instances
const calculators = Array.from({ length: 1000 }, () => makeCalculator());

// Memory: 1000 instances + 3000 function objects (3 methods × 1000 instances)
// Each instance: contains its own function objects
// Methods: duplicated for every instance

IVP insight: when instance quantity and method complexity vary independently, classes provide better memory efficiency when you have many instances. Closures pay a per-instance cost for each captured function.

However, when closures capture unique state that differs per instance, they are not duplicating anything meaningful. The memory trade-off only matters when methods could be shared but are not.

Garbage Collection: Closure Capture Can Retain Unnecessary Data

Closures can retain variables across multiple methods:

function makeHandler() {
    const largeArray = new Array(1000000).fill('data');  // 1M elements
    const someData = 'needed';

    return {
        // This closure only uses someData
        handleClick: () => console.log(someData),

        // But THIS closure uses largeArray!
        processData: () => largeArray.map(x => x.toUpperCase())
    };
}

// largeArray MUST be kept in memory because processData needs it
// Even if you never call processData!
const handler = makeHandler();

Why this happens: when returning multiple closures, all closures share the same lexical environment. If any closure references largeArray, it must be retained for all closures, even those that do not use it.

Solution: create separate closures when possible or explicitly null out unused variables.

Classes do not have this issue—each method can access only the fields it actually uses:

class Handler {
    constructor() {
        this.largeArray = new Array(1000000).fill('data');
        this.someData = 'needed';
    }

    handleClick() {
        console.log(this.someData);  // Only accesses someData
    }

    processData() {
        return this.largeArray.map(x => x.toUpperCase());  // Only accesses largeArray
    }
}

// Both fields exist, but GC can see which methods use which fields

IVP insight: when method lifetimes and data lifetimes vary independently, classes provide finer-grained memory management. Closures capture entire lexical environments, which can retain data longer than necessary.

Performance: Execution Speed

Change drivers:

1. Instantiation frequency: How often you create new instances
2. Method call frequency: How often you call methods on existing instances

These vary independently—you might create instances once and call methods millions of times, or vice versa.

Modern JavaScript engines (V8, SpiderMonkey) are highly optimized:

• Prototype lookups are highly optimized: inline caching makes class methods fast
• Closure captures are optimized: engines only capture variables actually referenced
• Closure creation cost: creating functions per instance has overhead
• No prototype sharing: more memory pressure on GC

When this matters:

• Hot code paths (game loops, parsers, real-time systems): Classes may be faster
• Many short-lived instances: Closure creation overhead accumulates
• Normal application code: Difference is negligible (microseconds)

IVP insight: when instantiation frequency and method call frequency vary independently, choose based on your bottleneck. Many instances with few calls favors classes (faster instantiation). Few instances with many calls means both perform similarly. Measure if uncertain.

Serialization: State Persistence

Change drivers:

1. State persistence: Need to serialize and transfer state
2. Behavior: Methods that operate on state

These vary independently—you might need to save state to disk or send it over network while keeping behavior local.

Classes separate data from methods naturally:

class Person {
    constructor(name, age) {
        this.name = name;
        this.age = age;
    }

    greet() { return `Hi, I'm ${this.name}`; }
}

const person = new Person('Alice', 30);
const json = JSON.stringify(person);  // {"name":"Alice","age":30}

// Reconstruct with methods
const restored = Object.assign(new Person('', 0), JSON.parse(json));
restored.greet();  // Works!

Closures cannot be serialized (captured scope is not serializable):

function makePerson(name, age) {
    return {
        greet: () => `Hi, I'm ${name}`  // Closure captures 'name'
    };
}

const person = makePerson('Alice', 30);
const json = JSON.stringify(person);  // {"greet":"() => `Hi, I'm ${name}`"} - BROKEN!

// Cannot reconstruct - the closure's captured scope is lost

When this matters:

• Need to persist state: Classes (with manual method reconstruction)
• Need to send over network: Classes or plain data objects (not closures)
• In-memory only: Closures work fine

IVP insight: when state persistence and behavior vary independently, separate data (serializable) from behavior (functions or methods). Classes make this separation natural—state goes to JSON, behavior is reconstructed. Closures conflate the two, making serialization impossible. This independence drives the Command-Query Separation pattern.

Debugging: Stack Traces

Change drivers:

1. Runtime behavior: Correctness of code execution
2. Developer experience: Debuggability and stack trace clarity

These vary independently—code can work correctly but be difficult to debug.

Classes have clear names in stack traces:

class PaymentProcessor {
    process() { throw new Error('Payment failed'); }
}

const processor = new PaymentProcessor();
processor.process();
// Error: Payment failed
//   at PaymentProcessor.process (file.js:3:15)  <- Clear class name

Closures may have anonymous functions:

const makeProcessor = () => ({
    process: () => { throw new Error('Payment failed'); }
});

const processor = makeProcessor();
processor.process();
// Error: Payment failed
//   at process (file.js:2:20)  <- Less context
//   at Object.process (file.js:2:14)  <- Anonymous

Solution: name your closures:

const makeProcessor = () => ({
    process: function processPayment() {  // Named function
        throw new Error('Payment failed');
    }
});

// Error: Payment failed
//   at processPayment (file.js:2:33)  <- Clear name!

IVP insight: when runtime behavior and developer experience vary independently, naming is a cross-cutting concern. Classes provide names automatically through syntax. Closures require discipline to add names—but when you do, debugging quality is comparable.

Concurrency and Shared State

Change drivers:

1. State evolution: How data changes over time
2. Concurrent access: Multiple threads or processes accessing the same data

These vary independently—single-threaded code might become multi-threaded without changing the business logic.

Closures encourage immutability:

// Closure with immutable state
function makeCounter(initial) {
    let count = initial;  // Private, mutable locally

    return {
        increment: () => ++count,
        getCount: () => count
    };
}

// No way to share state between instances - naturally isolated
const c1 = makeCounter(0);
const c2 = makeCounter(0);
// c1 and c2 cannot interfere with each other

Classes can share mutable state:

// Java: Shared mutable state (dangerous in concurrent contexts)
class Counter {
    private static int sharedCount = 0;  // Shared across all instances!
    private int instanceCount = 0;

    public synchronized void increment() {
        sharedCount++;      // Race condition if not synchronized!
        instanceCount++;
    }
}

In concurrent and parallel contexts, we observe different characteristics:

Closures:

• Naturally isolated: each closure has its own scope
• Encourages immutability: captured variables can be treated as constants
• Easier to reason about: no shared state by default
• Cannot share: if you need shared state, you need external coordination

Classes:

• Can share state: static variables allow coordination
• Need synchronization: mutable shared state requires locks or atomics
• Harder to reason about: potential for race conditions

Functional style with closures:

// Immutable approach - return new state instead of mutating
function makeCounter(count) {
    return {
        increment: () => makeCounter(count + 1),  // Return new counter
        getCount: () => count
    };
}

const c1 = makeCounter(0);
const c2 = c1.increment();  // New counter
c1.getCount();  // 0 (unchanged)
c2.getCount();  // 1 (new state)

IVP insight: when state evolution and concurrent access vary independently, immutable closures provide safety by default—no shared mutable state means no race conditions. Classes with static mutable state require explicit synchronization. The independence means you can add concurrency later without changing single-threaded logic if you use immutable closures.

Language Design Implications

The "poor man's" tension reveals deep differences in language philosophy.

Functional languages (Haskell, ML, Scheme):

• Primary abstraction: functions and closures
• Objects: encoded via closures or modules
• Strength: compositional, minimal boilerplate, first-class functions
• Weakness: type relationships less explicit (unless using algebraic data types)

Multi-paradigm languages (JavaScript, Python, Rust):

• Primary abstraction: both first-class
• JavaScript: true closures with mutable capture, prototype-based objects
• Python: closures with nonlocal for mutation, class-based OOP
• Rust: closures with explicit capture modes (move, borrow), trait-based polymorphism
• Strength: choose the right tool for the job
• Weakness: more ways to do things means more decisions

Change drivers:

1. Language constraints: what abstractions the language provides as primitives
2. Problem structure: what abstractions the problem naturally demands

IVP insight on language design: the best language design provides both abstractions as first-class citizens, allowing developers to align their choice with their change drivers. When a language forces you to use only one abstraction, you end up with "poor man's" implementations of the other.

Modern Java (8+) and C# have converged toward this ideal by adding first-class closures to traditionally class-based languages, though with more ceremony than languages designed for closures from the start.

The "poor man's" phenomenon emerges when language constraints and problem structure vary independently—you have a problem that demands closures, but your language only provides classes (or vice versa). The best solution is language support for both, letting you choose based on your actual change drivers, not language limitations.

The Decision Framework

Here is a systematic framework for choosing between closures and classes:

1. Do I need behavioral variants?

   • Multiple types implementing same interface: Classes
   • Single behavior with configuration: Closures

2. Do I need type relationships?

   • Inheritance, interfaces, abstract base classes: Classes
   • Just behavior and state, no hierarchy: Closures

3. Do I need polymorphic substitution?

   • Different types used interchangeably: Classes
   • Always the same type: Closures

4. How many methods operate on the state?

   • Multiple methods on shared state: Classes
   • Single operation or multiple independent operations: Closures

5. Is the abstraction domain-significant?

   • Represents a domain entity or concept: Classes
   • Infrastructure or utility behavior: Closures

6. What are your memory constraints?

   • Creating thousands of instances: Classes (shared methods via prototype)
   • Creating a few instances: Either works (memory difference negligible)

7. Do you need serialization?

   • Need to persist or transfer state: Classes or plain data objects (not closures)
   • In-memory only: Either works

8. Do you need dependency staging?

   • Multi-stage configuration: Closures with partial application
   • All dependencies upfront: Classes with constructor injection

9. Is concurrency a concern?

   • Multi-threaded access: Closures with immutability (safer by default)
   • Single-threaded: Either works

10. What does your language encourage?

    • Java, C#: Classes are first-class citizens (closures available but more ceremony)
    • JavaScript, Python: Both are first-class (choose based on problem)
    • Haskell, ML: Closures are natural (classes require encoding)

The key insight: do not choose based on dogma. Identify your change drivers, then select the abstraction that respects their independence.

The Takeaway

"Closures are a poor man's objects" and "objects are a poor man's closures" are both correct—in different contexts.

The Independent Variation Principle reveals when each is appropriate:

When change drivers demand type relationships and behavioral variants, think in objects (implemented via classes, prototypes, and so on).

When change drivers demand stateful behavior without type hierarchy, think in closures (functions capturing context).

Neither conceptual model is universally superior. Both are essential abstractions that excel in different scenarios.

The next time you model a problem with objects or classes, ask: do I need behavioral variety and type relationships, or am I just bundling state with a single operation?

The next time you model a problem with closures, ask: am I avoiding object-oriented patterns that would make my intent clearer, or would an object with multiple methods be artificial?

The answer guides you to the abstraction that respects your change drivers—and that is when code becomes maintainable, extensible, and genuinely well-designed.

---

References

The opening koan is from:

van Straaten, A. (2003). "RE: What's so cool about Scheme?" LL1 mailing list discussion.
https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg03277.html

The koan brilliantly captures the paradoxical relationship between closures and objects, inspiring this IVP-based analysis of when each abstraction excels.

---

Learn More

This article applies the Independent Variation Principle framework from:

Loth, Y. (2025). The Independent Variation Principle. Zenodo.
https://doi.org/10.5281/zenodo.17677316

The IVP paper provides a unified framework for understanding why certain abstractions work and when to apply them.

---