Where Objects Come From: Rethinking the Factory Pattern in JavaScript

At the beginning, creating objects feels effortless.

You write:

const user = {
  name: "Rishi",
  role: "user"
}

And move on.

There’s no ceremony.

No structure.

Just creation.

But as your application grows, something subtle starts to happen.

Objects stop being simple.

They begin to vary.

The Moment Creation Becomes Complex

At first, a user is just a user.

Then you introduce roles:

• admin
• guest
• premium

Each with different properties.

Different behaviors.

Different rules.

Now creation is no longer trivial.

It becomes conditional.

const user = {
  name,
  role: type === "admin" ? "admin" : "user"
}

And this logic doesn’t stay in one place.

It spreads.

Across files.

Across features.

Across assumptions.

The Hidden Cost of Scattered Creation

When object creation is duplicated, something fragile emerges.

Change one detail—

and you must remember to change it everywhere.

Miss one place—

and inconsistency appears.

The code still works.

But it no longer agrees with itself.

A Shift in Responsibility

The factory pattern introduces a quiet shift.

Instead of letting every part of your code create objects freely,

you assign that responsibility to a single place.

function createUser(type, name) {
  if (type === "admin") {
    return {
      name,
      role: "admin",
      permissions: ["all"]
    }
  }

  return {
    name,
    role: "user",
    permissions: ["read"]
  }
}

Now, creation is no longer scattered.

It is centralized.

Not Just Creation—But Control

What changes here is not just where objects are created—

but who controls their shape.

The rest of your code stops worrying about structure.

It simply asks:

const user = createUser("admin", "Rishi")

And trusts the result.

The complexity is hidden behind a single interface.

Decoupling the System

This is where the pattern becomes powerful.

You separate:

• the act of using an object
• from the knowledge of how it is built

The caller doesn’t know the internal structure.

And more importantly—

it doesn’t need to.

When Change Happens

Imagine your permission system evolves.

What was once:

permissions: ["all"]

becomes:

permissions: {
  read: true,
  write: true
}

Without a factory, this change spreads everywhere.

With a factory, it stays contained.

One place changes.

Everything else remains stable.

A Different Way to See It

The factory pattern is not about saving lines of code.

It’s about preventing complexity from leaking outward.

It draws a boundary around creation.

And inside that boundary, change is allowed.

Outside of it, stability is preserved.

Not Always Necessary

If object creation is simple, a factory adds little value.

But when variation appears—

when logic starts branching—

when duplication begins—

the pattern naturally emerges.

Not as a rule.

But as a solution.

A Final Thought

The factory pattern answers a question you don’t notice at first:

“Who decides what this object looks like?”

Without it, the answer is:

“Everyone.”

With it, the answer becomes:

“One place.”

And that difference is what turns scattered logic—

into a system that can grow without falling apart.