I. Factory Method - Creational Pattern

The Factory Method is a Creational Design Pattern that provides an interface for creating objects in a superclass, but allows subclasses — or in Go's case, a dedicated factory function — to decide which class to instantiate.

The core idea is simple: centralize object creation. Instead of scattering new(Latte) or new(Cappuccino) calls throughout your codebase, all creation logic lives in one place. Callers simply request a product by name and receive an interface — they never need to know the concrete type behind it.

This approach offers three key benefits:

• Decoupling: Callers depend on the ICoffeeDrink interface, not on concrete structs.

• Extensibility: Adding a new drink type only requires changing the factory function — nothing else.

• Centralized error handling: Unknown types return an error from one place, consistently.

II. Real-world Example

A coffee bar needs to serve multiple drink types — Latte and Cappuccino — without forcing the caller to know how each drink is constructed. A single factory function GetCoffeeDrink handles this: given a drink name, it returns the correct ICoffeeDrink implementation, or an error if the name is unrecognized.

This use case introduces the following components:

1. ICoffeeDrink (interface): The shared contract. Defines GetName() string — the only method callers need.

2. CoffeeDrink (base struct): Holds the name field and implements GetName(). Both Latte and Cappuccino embed this struct to inherit the behavior.

3. Latte: Embeds CoffeeDrink. Created privately via newLatte() with name = "Latte".

4. Cappuccino: Embeds CoffeeDrink. Created privately via newCappuccino() with name = "Cappuccino".

5. GetCoffeeDrink(name string): The factory function. Uses a switch statement to route the name to the correct private constructor. Returns (ICoffeeDrink, error).

The class diagram for the above scenario:

III. Implementation

• The shared interface:

1package factory_method
2
3type ICoffeeDrink interface {
4	GetName() string
5}

• The base struct that implements the interface:

1package factory_method
2
3type CoffeeDrink struct {
4	name string
5}
6
7func (me *CoffeeDrink) GetName() string {
8	return me.name
9}

• Latte — private constructor:

1package factory_method
2
3type Latte struct {
4	CoffeeDrink
5}
6
7func newLatte() *Latte {
8	return &Latte{
9		CoffeeDrink: CoffeeDrink{
10			name: "Latte",
11		},
12	}
13}

• Cappuccino — private constructor:

1package factory_method
2
3type Cappuccino struct {
4	CoffeeDrink
5}
6
7func newCappuccino() *Cappuccino {
8	return &Cappuccino{
9		CoffeeDrink: CoffeeDrink{
10			name: "Cappuccino",
11		},
12	}
13}

• The factory function — the single entry point:

1package factory_method
2
3import "fmt"
4
5const (
6	latteName      = "Latte"
7	cappuccinoName = "Cappuccino"
8)
9
10func GetCoffeeDrink(name string) (ICoffeeDrink, error) {
11	switch name {
12	case latteName:
13		return newLatte(), nil
14	case cappuccinoName:
15		return newCappuccino(), nil
16	default:
17		return nil, fmt.Errorf("unknown coffee drink: %s", name)
18	}
19}

• Running the example:

1fmt.Println("*** Example Factory Method ***")
2cappuccino, err := factory_method.GetCoffeeDrink("Cappuccino")
3if err != nil {
4	fmt.Println(err)
5} else {
6	fmt.Println(cappuccino.GetName())
7}
8
9latte, err := factory_method.GetCoffeeDrink("Latte")
10if err != nil {
11	fmt.Println(err)
12} else {
13	fmt.Println(latte.GetName())
14}
15
16_, err = factory_method.GetCoffeeDrink("Error")
17if err != nil {
18	fmt.Println(err)
19}
20fmt.Print("*** End of Factory Method ***\n\n\n")

With the output:

1*** Example Factory Method ***
2Cappuccino
3Latte
4unknown coffee drink: Error
5*** End of Factory Method ***

IV. Explain the example above

This example shows how GetCoffeeDrink acts as the single point of control for object creation, keeping the caller completely unaware of the concrete types.

1. Requesting a known drink — Cappuccino

1cappuccino, err := factory_method.GetCoffeeDrink("Cappuccino")
2if err != nil {
3    fmt.Println(err)
4} else {
5    fmt.Println(cappuccino.GetName())
6}

• GetCoffeeDrink receives "Cappuccino", matches the case cappuccinoName branch, and calls the private newCappuccino().

• The caller receives an ICoffeeDrink — not a *Cappuccino. It only knows about GetName().

• err is nil, so GetName() is called.

Log result:

Cappuccino

2. Requesting a known drink — Latte

latte, err := factory_method.GetCoffeeDrink("Latte")

Same flow — matches case latteName, calls newLatte(), returns ICoffeeDrink backed by a *Latte.

Log result:

Latte

3. Requesting an unknown drink — error handling

1_, err = factory_method.GetCoffeeDrink("Error")
2if err != nil {
3    fmt.Println(err)
4}

• No case matches "Error", so the default branch executes.

• fmt.Errorf("unknown coffee drink: %s", name) returns a descriptive error.

• The caller handles it gracefully without a panic or undefined behavior.

Log result:

unknown coffee drink: Error

4. Adding a new drink — zero changes to callers

To add an Espresso, you only need:

1. Create a private newEspresso() constructor.

2. Add case "Espresso": return newEspresso(), nil in GetCoffeeDrink.

No existing caller changes. No interface changes. This is the Open/Closed Principle in action: open for extension, closed for modification.

Summary

V. Conclusion

The Factory Method pattern is one of the most practical patterns in everyday Go code. A single factory function acting as the entry point for object creation keeps your codebase clean, extensible, and easy to test.

That said, it's not always necessary. If you only ever create one type of object, a direct constructor is simpler and more readable. The most important thing is to choose the solution that best fits your specific context.

Thank you for taking the time to read this article! 😊

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Full source code for Go design patterns: available here.