This lesson builds on Factory Method. An abstract factory is usually a group of factory methods that belong together.

Abstract Factory gives client code one object that creates a whole family of related products. Every product it returns belongs to the same variant, so the products always fit together. The client never names a concrete product class.

Start from products that must match

A media service stores uploads in blob storage and announces each upload on a message queue. It runs on AWS in production, on Google Cloud for one large customer, and in memory for tests. Two facts define the problem:

1. There is a family of related products: a blob store and a queue.
2. There are several variants of that family: AWS, GCP, and local.

This service supports one provider per deployment. Its startup configuration pairs storage, messaging, and credentials from that provider. Cross-provider use would need another supported integration. The family rule comes from this service's contract, not from a claim that providers can never interoperate.

Declare the family once, implement it per variant

Abstract Factory takes three moves:

1. Declare an interface for each product in the family: BlobStore and Queue. Every variant's product implements it.
2. Declare the abstract factory: an interface with one creation method per product, each returning the product interface.
3. Implement one concrete factory per variant. AwsKit returns only AWS products. GcpKit returns only GCP products.

The example shows the factory boundary. Bytes means Uint8Array. The concrete storage and queue classes stand in for provider adapters that implement the two product interfaces. Their SDK code is omitted.

type Bytes = Uint8Array;
interface BlobStore { put(key: string, data: Bytes): Promise<void>; }
interface Queue { send(message: object): Promise<void>; }

interface CloudKit {
  createStore(): BlobStore;
  createQueue(): Queue;
}

class AwsKit implements CloudKit {
  createStore() { return new S3Store(); }
  createQueue() { return new SqsQueue(); }
}

class GcpKit implements CloudKit {
  createStore() { return new GcsStore(); }
  createQueue() { return new PubSubQueue(); }
}

// Client code: only abstract types.
class UploadPipeline {
  private store: BlobStore;
  private queue: Queue;

  constructor(kit: CloudKit) {
    this.store = kit.createStore();
    this.queue = kit.createQueue();
  }

  async upload(key: string, data: Bytes) {
    await this.store.put(key, data);
    await this.queue.send({ type: "uploaded", key });
  }
}

If the client works only with abstract types, who creates the concrete factory? Usually the application, once, at startup. It reads configuration or the environment, picks the factory class, and passes the factory to everything that creates products.

const kit: CloudKit =
  config.cloud === "aws" ? new AwsKit() :
  config.cloud === "gcp" ? new GcpKit() :
  new LocalKit();

const pipeline = new UploadPipeline(kit);

Map the roles

Role	In this example	Job
Abstract products	BlobStore, Queue	Interfaces for each distinct but related product in the family
Concrete products	S3Store, GcsStore, SqsQueue, …	Variant-specific implementations of each abstract product
Abstract factory	CloudKit	Declares one creation method per abstract product
Concrete factories	AwsKit, GcpKit, LocalKit	Implement every creation method for one variant only
Client	UploadPipeline	Works with any factory and product through their interfaces

Concrete factories instantiate concrete products, but their method signatures return the abstract products. That keeps the client decoupled from the variant it happens to receive.

Know which change is cheap

Reach for it when products come in families

• your code must work with several families of related products, and you do not want it to depend on their concrete classes, because the variants are unknown ahead of time or you expect new ones
• a class works with several product types through a group of factory methods, and those methods blur its main responsibility. Move them into a separate factory object.

Implement it in six steps

1. Draw a matrix of distinct product types versus variants of those products.
2. Declare an abstract product interface for each product type, and make every concrete product implement its interface.
3. Declare the abstract factory interface with a creation method for every abstract product.
4. Implement one concrete factory class per variant.
5. Write initialization code that picks the concrete factory from configuration or the environment, then passes the factory to every class that creates products.
6. Find every direct call to a product constructor and replace it with a call to the matching factory method.

Name what it costs

You gain	You pay
Products from one factory are guaranteed to match	Many new interfaces and classes, so the code gets more complex
Client code is decoupled from concrete products	A new product type changes the factory interface and every concrete factory
Product creation lives in one place (single responsibility)
New variants without changing client code (open/closed)

Do not confuse it with its neighbors

Pattern	Relationship
Factory Method	Designs often start with Factory Method and evolve here. Abstract factory methods are frequently factory methods, though Prototype can implement them too.
Builder	Builder constructs one complex object step by step and lets you run extra steps before you take the result. Abstract Factory returns each product immediately and focuses on families.
Facade	When you only need to hide how a subsystem creates its objects, an abstract factory can replace a facade.
Bridge	When a bridge's abstractions work only with specific implementations, an abstract factory can encapsulate those pairings and hide them from the client.
Singleton	Abstract factories, builders, and prototypes can all be implemented as singletons. One factory per variant is usually enough.

Retrieve and apply

Continue to Builder for objects that are hard to construct in a single call.