JS Factory Pattern

Create objects via a factory function without exposing instantiation logic to callers

When to Use

• Object creation logic is complex and should be encapsulated
• The exact type of object to create is determined at runtime
• You want to return different implementations based on input without exposing

  new

  to callers

Instructions

1. Write a factory function (or static class method) that accepts configuration and returns the correct object.
2. The caller never uses

   new

   directly — they call the factory.
3. Validate inputs inside the factory before creating the object.
4. Return a consistent interface regardless of which concrete type was created.

function createUser(type, name) {
  const roles = {
    admin: { permissions: ['read', 'write', 'delete'] },
    editor: { permissions: ['read', 'write'] },
    viewer: { permissions: ['read'] },
  };

  if (!roles[type]) throw new Error(`Unknown user type: ${type}`);

  return {
    name,
    type,
    ...roles[type],
    greet() {
      return `Hi, I'm ${name} (${type})`;
    },
  };
}

const admin = createUser('admin', 'Alice');
console.log(admin.permissions); // ['read', 'write', 'delete']

Details

The Factory pattern is one of the most common patterns in JavaScript. Unlike

new ClassName()

, a factory function can return different types, apply caching, run validation, or perform async initialization.

Trade-offs:

• Callers cannot use

  instanceof

  to check the type (unless the factory returns a class instance)
• Can become a large switch/if-else block if not maintained

When NOT to use:

• When all instances are always the same type — just use

  new

  directly
• For very simple objects with no creation logic — plain object literals are sufficient

Source

https://patterns.dev/javascript/factory-pattern

Process

1. Read the instructions and examples in this document.
2. Apply the patterns to your implementation, adapting to your specific context.
3. Verify your implementation against the details and edge cases listed above.

Harness Integration

• Type: knowledge — this skill is a reference document, not a procedural workflow.
• No tools or state — consumed as context by other skills and agents.

Success Criteria

• The patterns described in this document are applied correctly in the implementation.
• Edge cases and anti-patterns listed in this document are avoided.