# Factory Method vs Abstract Factory in Go

> Published 2026-10-12T22:57:09.040Z on https://youblog.app/p/factory-method-vs-abstract-factory-in-go/
> Source video: https://www.youtube.com/watch?v=3Nc6RMhjH6g

The choice between Factory Method and Abstract Factory in Go comes down to one question: does one object need one collaborator, or does one context need a matched family of collaborators? A Simple Factory hides a switch behind a function, [Factory Method](https://refactoring.guru/design-patterns/factory-method) replaces that switch with a creation interface, and [Abstract Factory](https://refactoring.guru/design-patterns/abstract-factory) groups several related creation methods behind a single interface so payment and notification never drift apart.

## Simple Factory is not in the Gang of Four book

The pattern most teams call a factory is not one of the Gang of Four creational patterns. The book Design Patterns, published by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides in 1994, documents Factory Method and Abstract Factory but not Simple Factory, so any Simple Factory code you write is an informal convention rather than a catalogued pattern. That distinction matters because Simple Factory carries a trade-off the book never signed off on.

A Simple Factory takes one argument, usually a string, and returns one interface value. In Go that argument is a string and the body is a switch statement, so every new provider means editing the switch. Nothing is wrong with that when the set of providers is small and stable, and the speaker in the source video says he writes this kind of code himself and does not condemn it. The cost appears later, when the list of providers keeps growing and the same function is edited again and again.

## A runnable Simple Factory payment example in Go

A Simple Factory in Go is a function that maps a provider name to a concrete struct that satisfies one interface. Go has no classes and no implements keyword: a type satisfies an interface automatically when it declares the required method set. That means two structs, Pagarme and MercadoPago, each satisfying a method, will both satisfy the PaymentProcessor interface without any explicit declaration.

The factory below is the whole pattern. It takes a provider string and returns a PaymentProcessor.

```go
package main

import "fmt"

type PaymentProcessor interface {
	Pay(amount float64)
}

type Pagarme struct{}

func (p Pagarme) Pay(amount float64) {
	fmt.Printf("Paying %.2f with Pagarme\n", amount)
}

type MercadoPago struct{}

func (m MercadoPago) Pay(amount float64) {
	fmt.Printf("Paying %.2f with Mercado Pago\n", amount)
}

func SimplePaymentFactory(provider string) PaymentProcessor {
	switch provider {
	case "pagarme":
		return Pagarme{}
	case "mercadopago":
		return MercadoPago{}
	default:
		return nil
	}
}

func main() {
	processor := SimplePaymentFactory("pagarme")
	processor.Pay(100)
}
```

The switch is the deciding detail. A Simple Factory centralizes object creation, which is a real gain over scattering constructor calls across the codebase, but the creation logic and the product catalog live in the same file. Adding a provider is an edit to existing code, not an addition of new code.

## How Factory Method vs Abstract Factory differ

The core difference between Factory Method vs Abstract Factory is arity: Factory Method defines one creation method that produces one product, while Abstract Factory defines a factory interface with several creation methods that produce a family of related products. Both defer the choice of concrete type to an implementing type rather than a string argument. The Go community treats the two names loosely, and the confusion is common enough that the source video opens by saying many developers mix them up. The comparison below is the reference for the rest of this article.

## How do Factory Method and Abstract Factory compare?

Factory Method and Abstract Factory both move the new call out of the calling code, but they move it to different places. Factory Method pushes the decision to a factory type that implements a single creation method, so the client receives a creation interface rather than a product. Abstract Factory pushes it to a factory type that implements several creation methods, so the client receives one object that can build an entire family of products in one call site.

The table below lists the differences that change how you write the client code.

| Dimension | Factory Method | Abstract Factory |
| --- | --- | --- |
| Creation methods per factory | One | Two or more |
| Objects produced | A single product | A family of related products |
| Client receives | A creation interface, then builds the product | The factory interface, then builds several products |
| Effect on the switch statement | Removed | Removed |
| Typical trigger to use it | One product type varies | Several products must vary together |
| Cost in interfaces and types | Moderate | Higher |

The last two rows are what decide the choice in practice. If payment and notification always have to match the same provider, a single factory that can create only a payment processor leaves the matching logic to the caller, which is where mismatched pairs come from.

## The Go implementation of every factory pattern in this article

The implementations below cover all three patterns and follow the layout in the source video. The full set of Go files referenced here is not published in a repository by the video author, so treat the code as a transcription of the on-screen example rather than a downloadable module.

A Factory Method implementation has a creation interface and one factory type per product. The client never sees a string argument; it receives whatever implements the creation interface.

```go
type PaymentFactory interface {
	CreatePaymentProcessor() PaymentProcessor
}

type MercadoPagoFactory struct{}

func (MercadoPagoFactory) CreatePaymentProcessor() PaymentProcessor {
	return MercadoPago{}
}

type PagarmeFactory struct{}

func (PagarmeFactory) CreatePaymentProcessor() PaymentProcessor {
	return Pagarme{}
}

func ProcessPayment(factory PaymentFactory, amount float64) {
	processor := factory.CreatePaymentProcessor()
	processor.Pay(amount)
}
```

An Abstract Factory implementation adds a second product interface for notification and a factory interface with a method for each product.

```go
type NotificationService interface {
	SendNotification(message string)
}

type BillingFactory interface {
	CreatePaymentProcessor() PaymentProcessor
	CreateNotificationService() NotificationService
}

type PagarmeFactory struct{}

func (PagarmeFactory) CreatePaymentProcessor() PaymentProcessor {
	return Pagarme{}
}

func (PagarmeFactory) CreateNotificationService() NotificationService {
	return PagarmeNotification{}
}
```

One detail from the video is worth keeping: the client function receives a BillingFactory and an amount, and calls both creation methods on the same value. The function body never names a provider. Adding a new provider means writing a new factory type and a new set of product structs, with no change to the client function.

## When Abstract Factory earns its extra interfaces

Abstract Factory earns its cost when several products must vary together, which is why the pattern is called a factory of families. The payment and notification example is exactly that case: a Pagarme payment must be followed by a Pagarme notification, and a Mercado Pago payment must be followed by a Mercado Pago notification.

That coupling is the whole point. If your Go code creates two or more objects that must stay matched, a single interface that returns both of them removes a real class of bug before it can be written. The [Abstract Factory pattern](https://refactoring.guru/design-patterns/abstract-factory) is only worth its interfaces when that constraint exists.

| Setup | Products that vary together | Interfaces worth adding |
| --- | --- | --- |
| Single provider, single product | None | None, or one Factory Method |
| Single provider, product plus notifier | One matched pair | One factory per family |
| Several providers, payment plus notification | Every product | Abstract Factory |
| Providers added on a schedule | Every product, per release | Abstract Factory |

The pattern does not, on its own, guarantee that the pairing stays correct. It guarantees that a single `BillingFactory` value produces both products from the same provider, which removes the class of bug where a caller builds a pagarme processor and a Mercado Pago notifier. If a provider only needs a payment processor and no notification, the second creation method has nothing useful to return and Abstract Factory is the wrong shape for the problem. The rule the video states is that if the program is small you will not have this complexity, and if you have more complexity than that, Factory Method is the recommendation. The [Go design patterns](https://github.com/tmrts/go-patterns) collection shows the same family of shapes in idiomatic Go.

The source video is 35 minutes long and was published on 20 January 2025 on the Full Cycle channel, where the Go examples are shown as a rough draft rather than an edited production codebase. The speaker notes at the end that patterns help software grow in a decent way, and warns against patternitis, the habit of applying a pattern wherever you recognize a shape. That warning applies directly here: Simple Factory is the fastest to write and the easiest to read for a small provider list, and the more formal patterns only pay off when the object graph actually grows. The [Go Blog](https://go.dev/blog/) has more on keeping interfaces small.

> If a provider only needs one product, the second creation method has nothing honest to return.

- Reach for Abstract Factory when two or more products must match.
- Stay with Factory Method when only one product varies.
- Stay with Simple Factory when the provider list is short and stable.

---

Once the family stops varying together, the extra interfaces are cost without benefit.

## Where the example stops and the rest of the pattern goes

The payment example covers the creation half of the pattern, but GoF patterns split a factory into a creator and the products it produces, and the book describes concrete Factory Method subclasses that override an inherited creation method. Go has no inheritance, so the Go version above substitutes an interface for the abstract creator and structs for the subclasses. The behavior is the same: the client calls a creation method and receives a product without knowing the concrete type.

If you want to go deeper into the language and the surrounding tooling, there are Brazilian Portuguese resources aimed at Go, TypeScript and Node.js, including Crazystack Typescript at https://crazystack.com.br, and the Skala Blog covers adjacent engineering topics in written form. Gustavo Dev Doido also publishes Go and TypeScript material, and the Bootcamp do Dev Doido is the program channel for that style of hands-on content. If you are working with Go specifically, keep the same posture the video recommends: implement the pattern against a real second provider before you decide whether the extra interface is earning its place.

For the Gang of Four catalog itself, the original 1994 book is still the reference for what counts as a documented pattern and what does not, and the Go documentation covers the interface semantics that make the Go versions above compile without an implements keyword.

## Frequently asked questions about factory patterns

Factory Method defines one creation method returning one product; Abstract Factory defines an interface with several creation methods returning a family of related products, protecting against mismatched pairs. Most teams should start with a plain function or Simple Factory, move to Factory Method when a second provider appears, and adopt Abstract Factory only when several products must vary together. Go satisfies interfaces implicitly, with no `implements` keyword.

- **What is the difference between Factory Method and Abstract Factory?** Factory Method defines one creation method that returns one product, while Abstract Factory defines a factory interface with several creation methods that return a family of related products. In the payment example, Factory Method returns a payment processor and Abstract Factory returns a payment processor plus a matching notification service.

- **Is Simple Factory a real design pattern?** No. The 1994 Gang of Four book documents Factory Method and Abstract Factory but does not include Simple Factory, so it is an informal convention. It still works well when the number of concrete implementations is small and rarely changes.

- **Does Go need an implements keyword to satisfy an interface?** No. Go satisfies an interface implicitly when a type declares the required method set, so a struct with a Pay method automatically satisfies a PaymentProcessor interface that requires Pay.

- **When should you avoid Abstract Factory?** Avoid it when products do not need to vary together, or when the program is small enough that a single factory method or a simple function covers the case. Extra interfaces add indirection that costs more than it saves when there is only one product.

- **Can Factory Method replace a switch statement entirely?** Yes. The caller receives a factory value that implements the creation interface instead of passing a string into a switch, so adding a provider means adding a new factory type rather than editing existing branches.

- **Does Abstract Factory prevent mismatched product pairs?** It prevents the specific mismatch where one billing context builds products from two different providers, because both products come from the same factory value. It does not validate that a provider's own products are logically consistent with each other.

- **What is the Open/Closed Principle in this context?** The client function is closed for modification, because it never names a concrete provider, and open for extension, because a new provider arrives as a new factory type. The source video uses this framing for Factory Method.

- **Is Factory Method the same as the Strategy pattern?** No. Strategy is a behavioral pattern that swaps algorithms at runtime, while Factory Method is a creational pattern that swaps object creation. The source video warns that these two are commonly conflated in practice.

- **Which pattern should you pick for a small Go service?** Start with the smallest option that works, which is usually a plain function or a Simple Factory, and move to Factory Method when a second provider appears. Introduce Abstract Factory only when several products must vary together for the same provider.

## Turn the explanation into an article

The hardest part of a video like this one is that the value sits in the sequence: interface, then concrete struct, then factory, then client function. Written out, that sequence becomes a reference you can return to; in a 35-minute recording, it is easier to lose the thread halfway through.

If you have an explanation like this one sitting inside a YouTube video, the reasoning and the code examples can be reworked into a written article that keeps the order intact and lets a reader follow it at their own pace. Paste the video URL into [Skala Blog](https://skalablog.com), let it transcribe the recording, and turn the transcript into a draft you can edit and publish.

[Source video](https://www.youtube.com/watch?v=3Nc6RMhjH6g)