DEV Community: Eduardo

Go Design Patterns #4: Abstract Factory

Eduardo — Tue, 22 Oct 2024 15:58:30 +0000

Abstract Factory is a creational design pattern that lets you create related objects without specifying their concrete classes.

Problem Statement

Imagine you are developing a GUI toolkit that should support multiple look-and-feel standards (e.g., Windows, macOS, Linux). Each look-and-feel standard requires a different set of UI components such as buttons, checkboxes, and scrollbars.

Without the Abstract Factory pattern, you would have to write a lot of conditional code to handle the creation of these components based on the current look-and-feel standard. This approach is not scalable and makes the codebase difficult to maintain and extend.

By using the Abstract Factory pattern, you can create an interface for creating families of related objects (e.g., buttons, checkboxes, scrollbars) and implement this interface for each look-and-feel standard. This way, the client code can work with any look-and-feel standard without knowing the specifics of how the components are created.

Real-World Example

Consider a furniture factory that produces chairs and tables in different styles such as classic and modern.

Each style requires a different set of components (e.g., legs, backrest, armrests) and materials (e.g., wood, metal, plastic).

Implementation

Run the example by running go run abstract-factory/main.go.

package main

import "fmt"

// Abstract Factory
type FurnitureFactory interface {
    MakeChair() Chair
    MakeTable() Table
}

func NewFurnitureFactory(style string) (FurnitureFactory, error) {
    if style == "classic" {
        return &Classic{}, nil
    }

    if style == "modern" {
        return &Modern{}, nil
    }

    return nil, fmt.Errorf("Style %s is not supported", style)
}

type Chair struct {
    Name     string
    Material string
}

type Table struct {
    Name     string
    Material string
}

// Concrete Classic Factory
type Classic struct{}

func (a *Classic) MakeChair() Chair {
    return Chair{
        Name:     "Classic Chair",
        Material: "Wood",
    }
}

func (a *Classic) MakeTable() Table {
    return Table{
        Name:     "Classic Table",
        Material: "Wood",
    }
}

// Concrete Modern Factory
type Modern struct{}

func (n *Modern) MakeChair() Chair {
    return Chair{
        Name:     "Modern Chair",
        Material: "Plastic",
    }
}

func (n *Modern) MakeTable() Table {
    return Table{
        Name:     "Modern Table",
        Material: "Plastic",
    }
}

func main() {
    factory, _ := NewFurnitureFactory("classic")

    chair := factory.MakeChair()
    table := factory.MakeTable()

    fmt.Printf("Chair: %s\n", chair.Name)
    fmt.Printf("Table: %s\n", table.Name)

    factory, _ = NewFurnitureFactory("modern")

    chair = factory.MakeChair()
    table = factory.MakeTable()

    fmt.Printf("Chair: %s\n", chair.Name)
    fmt.Printf("Table: %s\n", table.Name)
}

Explanation

This code demonstrates the Abstract Factory pattern by creating furniture (chairs and tables) in different styles (classic and modern). It defines an interface for creating families of related objects and concrete implementations for each style, allowing easy scalability and maintenance.

Go Design Patterns #3: Factory

Eduardo — Fri, 11 Oct 2024 16:03:31 +0000

Factory Method

The Factory Method is a creational design pattern that provides an interface for creating objects, but allows subclasses to alter the type of objects that will be created. Instead of directly instantiating objects using new, the Factory Method delegates the responsibility of object creation to subclasses or methods, promoting flexibility and scalability.

Problem Statement

When there's the need to create objects, but you don’t know in advance the exact class of the object that will be required. The application needs to handle different types of objects that share common behavior but differ in their implementation. Additionally, you want to avoid modifying your code each time a new type of object is added or when the way objects are created changes.

Specific Problems It Solves

Complex object creation: Directly instantiating classes can tie your code to specific implementations, making it rigid and difficult to maintain.
Dynamic object creation: In many cases, the type of object required may not be known until runtime, and this decision should be flexible.
Encapsulation of instantiation: Object creation logic should be separated from the client code, so changes in how objects are created don't affect the rest of the system.
Scalability: When you need to add new types of products (objects), you want a scalable solution that avoids modifying existing code.

Real-World Example

Imagine a car factory where you place an order for a car, but depending on your preferences (e.g., electric or gas), the factory assembles and provides you with the appropriate car type. The client doesn't need to know the specific details of car assembly—they just receive the product.

Implementation

package main

import (
    "fmt"
    "os"
)

// Step 1: Define the Product Interface
type Car interface {
    Drive() string
    FuelType() string
}

// Step 2: Concrete Products (Electric Car and Gas Car)
type ElectricCar struct{}

func (e *ElectricCar) Drive() string {
    return "Driving an electric car"
}

func (e *ElectricCar) FuelType() string {
    return "Powered by electricity"
}

type GasCar struct{}

func (g *GasCar) Drive() string {
    return "Driving a gas-powered car"
}

func (g *GasCar) FuelType() string {
    return "Powered by gasoline"
}

// Step 3: Define the Factory Interface
type CarFactory interface {
    CreateCar(brand string) Car
}

type carFactory struct{}

func (carFactory *carFactory) CreateCar() Car {
    carPreference := os.Getenv("CAR_PREFERENCE")

    if carPreference == "electric" {
        return &ElectricCar{}
    }

    // here we just instantiate the struct, but you could also 
    // have another functions to help create the object if it's complex
    return &GasCar{}
}

// Step 4: Client Code
func main() {
    // Client uses the factory to create objects
    carFactory := carFactory{}

    // Creating a Gas Car
    gasCar := carFactory.CreateCar()
    fmt.Println(gasCar.Drive())    // Output: Driving a gas-powered car
    fmt.Println(gasCar.FuelType()) // Output: Powered by gasoline

    // Creating an Electric Car
    os.Setenv("CAR_PREFERENCE", "electric")
    electricCar := carFactory.CreateCar()
    fmt.Println(electricCar.Drive())    // Output: Driving an electric car
    fmt.Println(electricCar.FuelType()) // Output: Powered by electricity
}

Product Interface: Defines a common interface (Car) with methods Drive() and FuelType().

Concrete Products: Implements the interface with specific classes (ElectricCar, GasCar) that define their behavior.

Factory Interface: Specifies a method (CreateCar()) for creating Car objects.

Factory Logic: The factory decides which type of car to create based on the client's preferences. This is exampled here by using environment variables, but it could be based on any logic.

Client Code: Requests cars from the factory without knowing the creation details, using the returned objects through the common interface.

Go Design Patterns #2: Builder

Eduardo — Fri, 11 Oct 2024 15:49:24 +0000

Builder

The Builder Pattern is a creational design pattern that provides a flexible solution for constructing complex objects step by step. It allows you to create different representations of an object using the same construction process.

Problem Statement

When creating an object involves multiple steps or parameters, managing the construction process can become cumbersome.
You want to avoid a "telescoping constructor" problem (where constructors take many parameters) and ensure that your object is immutable after creation.

Benefits of the Builder Pattern

Flexibility: Easily construct different representations of an object.
Readability: Method chaining makes the construction process clear and concise.
Encapsulation: The construction logic is encapsulated within the builder, separating it from the client code.

Real-World Example

Consider building a computer. A computer can have various components like CPU, RAM, storage, etc.

Instead of requiring all these parameters in a constructor, the builder pattern allows you to set each component step by step.

Implementation

package main

import "fmt"

// Product
type Computer struct {
    CPU     string
    RAM     string
    Storage string
    OS      string
}

// Builder Interface
type ComputerBuilder interface {
    SetCPU(cpu string) ComputerBuilder
    SetRAM(ram string) ComputerBuilder
    SetStorage(storage string) ComputerBuilder
    SetOS(os string) ComputerBuilder
    Build() *Computer
}

// Concrete Builder
type PCBuilder struct {
    computer *Computer
}

func NewPCBuilder() *PCBuilder {
    return &PCBuilder{&Computer{}}
}

func (b *PCBuilder) SetCPU(cpu string) ComputerBuilder {
    b.computer.CPU = cpu
    return b
}

func (b *PCBuilder) SetRAM(ram string) ComputerBuilder {
    b.computer.RAM = ram
    return b
}

func (b *PCBuilder) SetStorage(storage string) ComputerBuilder {
    b.computer.Storage = storage
    return b
}

func (b *PCBuilder) SetOS(os string) ComputerBuilder {
    b.computer.OS = os
    return b
}

func (b *PCBuilder) Build() *Computer {
    return b.computer
}

// Client Code
func main() {
    builder := NewPCBuilder()

    computer := builder.
        SetCPU("Intel i7").
        SetRAM("16GB").
        SetStorage("1TB SSD").
        SetOS("Windows 7").
        Build()

    fmt.Printf("Computer built: %+v\n", computer)
}

Product (Computer): Represents the complex object that will be built with various attributes.

Builder Interface (ComputerBuilder): Defines methods for setting each component of the product.

Concrete Builder (PCBuilder): Implements the builder interface.

Provides methods to set CPU, RAM, Storage, and OS, returning the builder itself for method chaining.
The Build() method returns the final Computer object.

Client Code: Creates a new builder instance.

Configures the computer step by step using method chaining.
Calls Build() to retrieve the final product.

Go Design Patterns #1: Singleton

Eduardo — Mon, 07 Oct 2024 19:56:27 +0000

Design patterns are tried-and-tested solutions to common problems that arise in software design. They provide a template or guide for solving these problems in a flexible and reusable way.

Each pattern represents a best practice that developers can adapt to their specific context. Design patterns are often classified into three main categories.

To kickstart this series, let's talk about the Singleton pattern.

Singleton

The Singleton pattern ensures that a class has only one instance and provides a global point of access to that instance.

This is useful in cases where you need to manage a shared resource, such as database connections or configuration settings.

Problem Statement

Often there is the need to ensure that only one instance of a class exists, such as when managing configurations or interacting with hardware resources. Without Singleton, creating multiple instances can lead to issues like inconsistent data or resource locks.

This is very common to happen when working with asynchronous code, where multiple goroutines can create new instances of a class or access shared resources.

Real-World Example

Consider a database connection pool: If multiple parts of your application create new connections at the same time, you may end up with redundant or conflicting database interactions. A Singleton ensures only one connection is created and used across the application.

Implementation

package main

import (
    "fmt"
    "sync"
)

type Singleton interface {
    DoSomething() string
}

type singleton struct{}

var lock = &sync.Mutex{}

var instance *singleton

func NewSingletonInstance() *singleton {
    if instance == nil {
        lock.Lock()
        defer lock.Unlock()
        if instance == nil {
            fmt.Println("Creating single instance now.")
            instance = &singleton{}
        } else {
            fmt.Println("Single instance already created.")
        }
    } else {
        fmt.Println("Single instance already created.")
    }

    return instance
}

func (s *singleton) DoSomething() string {
    return "Doing something."
}

func main() {
    instance1 := NewSingletonInstance()
    instance2 := NewSingletonInstance()
    fmt.Printf("%p\n", instance1)
    fmt.Printf("%p\n", instance2)
}

The function NewSingletonInstance ensures that only one instance of singleton is created, even when called multiple times.

First, it checks if instance is nil (i.e., no instance has been created yet).
If instance is nil, it locks the section of code using lock.Lock() to prevent multiple goroutines from entering this section simultaneously.
After locking, a second check is performed to ensure that no other goroutine created the instance between the first check and the time the lock was acquired.
If instance is still nil, a new singleton instance is created and assigned to the global variable.
The sync.Mutex and double-checked locking ensure that the creation of the singleton instance is thread-safe, preventing multiple goroutines from creating separate instances.