Go Design Patterns: Die wichtigsten Muster und Interview-Fragen fuer Go-Entwickler

Go-Design-Patterns gehoeren zu den am haeufigsten abgefragten Themen in technischen Vorstellungsgespraechen fuer Backend-Entwickler. Anders als in Sprachen wie Java oder C++ setzt Go nicht auf klassische Vererbung und komplexe Klassenhierarchien, sondern auf Komposition, Interfaces und Funktionen hoeherer Ordnung. Dieses Paradigma fuehrt zu elegantem, wartbarem Code -- verlangt aber ein tiefes Verstaendnis der idiomatischen Patterns, die sich in der Go-Community etabliert haben. Dieser Artikel stellt die sechs wichtigsten Design Patterns in Go vor, jeweils mit produktionsreifem Code, und schliesst mit typischen Interview-Fragen ab, die in Gespraechen fuer Go-Positionen regelmaessig gestellt werden.

Functional Options: Flexible Konfiguration ohne Konstruktor-Ueberladung

Das Functional-Options-Pattern ist eines der bekanntesten idiomatischen Patterns in Go. Es loest ein grundlegendes Problem: Go kennt weder optionale Parameter noch Konstruktor-Ueberladung. Ohne dieses Pattern muesste jede Konfigurationsoption als separater Parameter uebergeben werden, was bei wachsender Komplexitaet schnell unuebersichtlich wird.

Die Kernidee besteht darin, Konfigurationsoptionen als Funktionen zu definieren, die ein Struct modifizieren. Der Konstruktor akzeptiert eine variable Anzahl dieser Funktionen und wendet sie nacheinander auf eine Standardkonfiguration an. So lassen sich beliebig viele Optionen kombinieren, ohne die API zu brechen.

package server

import (
	"time"
	"log/slog"
)

// Server holds the HTTP server configuration.
type Server struct {
	host         string
	port         int
	timeout      time.Duration
	maxConns     int
	logger       *slog.Logger
}

// Option defines a functional option for Server.
type Option func(*Server)

// WithPort sets the server port.
func WithPort(port int) Option {
	return func(s *Server) {
		s.port = port
	}
}

// WithTimeout sets the request timeout.
func WithTimeout(d time.Duration) Option {
	return func(s *Server) {
		s.timeout = d
	}
}

// WithMaxConns sets the maximum concurrent connections.
func WithMaxConns(n int) Option {
	return func(s *Server) {
		s.maxConns = n
	}
}

// New creates a Server with sensible defaults and applies options.
func New(host string, opts ...Option) *Server {
	srv := &Server{
		host:     host,
		port:     8080,           // default port
		timeout:  30 * time.Second, // default timeout
		maxConns: 100,            // default max connections
		logger:   slog.Default(),
	}
	for _, opt := range opts {
		opt(srv)
	}
	return srv
}

Das Pattern bietet mehrere Vorteile: Die API bleibt abwaertskompatibel, wenn neue Optionen hinzugefuegt werden. Standardwerte sind klar definiert und an einer einzigen Stelle dokumentiert. Und der aufrufende Code ist selbsterklaerend -- server.New("localhost", WithPort(9090), WithTimeout(5*time.Second)) liest sich fast wie natuerliche Sprache. Bekannte Go-Projekte wie grpc-go und zap setzen dieses Pattern produktiv ein.

Strategy Pattern: Austauschbare Algorithmen ueber Interfaces

Das Strategy Pattern trennt einen Algorithmus von seinem Kontext, sodass unterschiedliche Implementierungen zur Laufzeit ausgetauscht werden koennen. In Go geschieht das nicht ueber abstrakte Klassen, sondern ueber Interfaces -- ein natuerlicher Fit, da Go Interfaces implizit implementiert werden.

Ein typisches Beispiel ist die Zahlungsabwicklung, bei der verschiedene Zahlungsmethoden (Kreditkarte, Bankueberweisung, digitale Wallets) die gleiche Schnittstelle implementieren. Der Checkout-Prozess arbeitet ausschliesslich gegen das Interface, ohne die konkrete Implementierung kennen zu muessen.

package payment

import "fmt"

// Processor defines the strategy interface.
type Processor interface {
	Pay(amount float64) (string, error)
}

// CreditCard implements Processor for card payments.
type CreditCard struct {
	CardNumber string
	Expiry     string
}

func (c *CreditCard) Pay(amount float64) (string, error) {
	// Charge the card via payment gateway
	return fmt.Sprintf("charged %.2f to card ending %s", amount, c.CardNumber[len(c.CardNumber)-4:]), nil
}

// BankTransfer implements Processor for wire transfers.
type BankTransfer struct {
	IBAN string
}

func (b *BankTransfer) Pay(amount float64) (string, error) {
	return fmt.Sprintf("initiated transfer of %.2f to %s", amount, b.IBAN), nil
}

// Checkout processes a payment using the given strategy.
func Checkout(p Processor, amount float64) error {
	receipt, err := p.Pay(amount)
	if err != nil {
		return fmt.Errorf("payment failed: %w", err)
	}
	fmt.Println(receipt)
	return nil
}

Der entscheidende Punkt fuer Interviews: In Go muessen Typen ein Interface nicht explizit deklarieren. Jeder Typ, der die Methode Pay(float64) (string, error) besitzt, erfuellt automatisch das Processor-Interface. Diese implizite Erfuellung foerdert lose Kopplung und macht das Hinzufuegen neuer Strategien trivial -- es genuegt, einen neuen Typ mit der passenden Methode zu erstellen.

Factory Functions: Sichere Objekterzeugung mit Validierung

Go kennt keine Konstruktoren im klassischen Sinne. Stattdessen verwendet die Sprache Factory Functions -- oeffentliche Funktionen, die eine Instanz eines Typs erzeugen und zurueckgeben. Dieses Pattern ist besonders dann wichtig, wenn bei der Erzeugung Validierungen notwendig sind oder Ressourcen initialisiert werden muessen.

Die Konvention NewTypeName ist in Go fest etabliert und wird von der gesamten Standardbibliothek verwendet. Die Rueckgabe eines Fehlers als zweitem Wert signalisiert dem Aufrufer, dass die Erzeugung fehlschlagen kann.

package pool

import (
	"errors"
	"sync"
)

// ConnPool manages a pool of reusable connections.
type ConnPool struct {
	mu       sync.Mutex
	conns    []Conn
	maxSize  int
}

// Conn represents a database connection.
type Conn struct {
	ID     int
	Active bool
}

// NewConnPool validates parameters and returns an initialized pool.
func NewConnPool(maxSize int) (*ConnPool, error) {
	if maxSize <= 0 {
		return nil, errors.New("pool: maxSize must be positive")
	}
	return &ConnPool{
		conns:   make([]Conn, 0, maxSize),
		maxSize: maxSize,
	}, nil
}

// Acquire returns a connection from the pool.
func (p *ConnPool) Acquire() (*Conn, error) {
	p.mu.Lock()
	defer p.mu.Unlock()
	for i := range p.conns {
		if !p.conns[i].Active {
			p.conns[i].Active = true
			return &p.conns[i], nil
		}
	}
	if len(p.conns) >= p.maxSize {
		return nil, errors.New("pool: no available connections")
	}
	c := Conn{ID: len(p.conns) + 1, Active: true}
	p.conns = append(p.conns, c)
	return &p.conns[len(p.conns)-1], nil
}

Der Connection-Pool veranschaulicht mehrere Best Practices: Die Factory Function validiert Eingaben vor der Erzeugung. Interne Felder wie mu und conns sind unexported und somit vor externem Zugriff geschuetzt. Und der sync.Mutex schuetzt den Pool vor Race Conditions bei konkurrierendem Zugriff -- ein Aspekt, der in Go-Interviews besonders haeufig abgefragt wird.

Observer Pattern mit Channels: Ereignisgesteuerte Architektur

Das Observer Pattern entkoppelt Event-Produzenten von Event-Konsumenten. Waehrend klassische Implementierungen auf Callback-Funktionen setzen, bietet Go mit Channels eine erstklassige Sprachprimitive, die das Pattern auf natuerliche und goroutine-sichere Weise umsetzt.

Ein Event-Bus verwaltet eine Map von Topics zu Channel-Slices. Subscriber registrieren sich fuer ein Topic und erhalten einen Lese-Channel zurueck. Publisher senden Events an alle registrierten Channels eines Topics.

package events

import "sync"

// Event carries a topic and payload.
type Event struct {
	Topic   string
	Payload any
}

// Bus manages subscriptions and event dispatch.
type Bus struct {
	mu          sync.RWMutex
	subscribers map[string][]chan Event
}

// NewBus creates an event bus.
func NewBus() *Bus {
	return &Bus{
		subscribers: make(map[string][]chan Event),
	}
}

// Subscribe returns a channel that receives events for a topic.
func (b *Bus) Subscribe(topic string) <-chan Event {
	ch := make(chan Event, 16) // buffered to avoid blocking publisher
	b.mu.Lock()
	b.subscribers[topic] = append(b.subscribers[topic], ch)
	b.mu.Unlock()
	return ch
}

// Publish sends an event to all subscribers of the topic.
func (b *Bus) Publish(topic string, payload any) {
	b.mu.RLock()
	defer b.mu.RUnlock()
	for _, ch := range b.subscribers[topic] {
		select {
		case ch <- Event{Topic: topic, Payload: payload}:
		default:
			// subscriber too slow, drop event
		}
	}
}

Mehrere Details verdienen Aufmerksamkeit: Die gepufferten Channels (Kapazitaet 16) verhindern, dass ein langsamer Subscriber den Publisher blockiert. Der select-Block mit default-Case in Publish sorgt fuer non-blocking Sends -- langsame Subscriber verlieren Events, statt das gesamte System aufzuhalten. Und der sync.RWMutex erlaubt parallele Reads (mehrere gleichzeitige Publishes), waehrend Writes (neue Subscriptions) exklusiven Zugriff erhalten. Dieses Pattern findet sich in Microservice-Architekturen, Event-Sourcing-Systemen und Echtzeit-Anwendungen.

Middleware Pattern: Komposition von HTTP-Handlern

Das Middleware Pattern ist in Go-Webservern allgegenwaertig. Es basiert auf einem einfachen Prinzip: Eine Middleware ist eine Funktion, die einen http.Handler entgegennimmt und einen neuen http.Handler zurueckgibt. Dadurch lassen sich Querschnittsbelange wie Logging, Authentifizierung, Rate-Limiting und CORS als unabhaengige, stapelbare Schichten implementieren.

package middleware

import (
	"log/slog"
	"net/http"
	"time"
)

// Logging records request duration and status.
func Logging(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		start := time.Now()
		wrapped := &statusWriter{ResponseWriter: w, status: 200}
		next.ServeHTTP(wrapped, r)
		slog.Info("request",
			"method", r.Method,
			"path", r.URL.Path,
			"status", wrapped.status,
			"duration", time.Since(start),
		)
	})
}

// statusWriter captures the HTTP status code.
type statusWriter struct {
	http.ResponseWriter
	status int
}

func (w *statusWriter) WriteHeader(code int) {
	w.status = code
	w.ResponseWriter.WriteHeader(code)
}

// Chain applies middleware in order: first listed = outermost.
func Chain(h http.Handler, mw ...func(http.Handler) http.Handler) http.Handler {
	for i := len(mw) - 1; i >= 0; i-- {
		h = mw[i](h)
	}
	return h
}

Die Chain-Funktion iteriert die Middleware-Liste rueckwaerts, damit die zuerst genannte Middleware die aeusserste Schicht bildet. Der statusWriter nutzt Struct-Embedding, um den http.ResponseWriter zu wrappen und den Statuscode abzufangen -- ein Muster, das in der Go-Standardbibliothek selbst an vielen Stellen verwendet wird. Frameworks wie Chi und Echo basieren intern auf genau diesem Prinzip, bieten aber zusaetzliche Convenience-Funktionen.

Komposition durch Struct Embedding: Go's Alternative zur Vererbung

Struct Embedding ist Go's Mechanismus, um Felder und Methoden eines Typs in einen anderen einzubetten. Anders als Vererbung erzeugt Embedding keine "is-a"-Beziehung, sondern eine "has-a"-Beziehung mit syntaktischem Zucker: Die Felder und Methoden des eingebetteten Typs werden promoted und koennen direkt aufgerufen werden.

package models

import "time"

// Timestamps provides common audit fields.
type Timestamps struct {
	CreatedAt time.Time
	UpdatedAt time.Time
}

// User embeds Timestamps to gain CreatedAt/UpdatedAt.
type User struct {
	Timestamps
	ID    int
	Email string
}

// Order also embeds Timestamps.
type Order struct {
	Timestamps
	ID     int
	UserID int
	Total  float64
}

Durch das Embedding koennen sowohl User als auch Order direkt auf CreatedAt und UpdatedAt zugreifen, ohne diese Felder redundant zu definieren. Wenn der Timestamps-Typ Methoden besitzt (etwa MarkUpdated()), werden diese ebenfalls promoted. In Interviews wird haeufig gefragt, worin der Unterschied zur Vererbung liegt: Embedding ist Delegation, nicht Subtyping. Ein User ist kein Timestamps -- er enthaelt einen. Und bei Namenskonflikten zwischen eingebetteten Typen muss der Zugriff explizit qualifiziert werden.

Typische Interview-Fragen zu Go Design Patterns

Die folgenden Fragen werden in technischen Interviews fuer Go-Positionen regelmaessig gestellt. Jede Frage zielt auf ein tiefes Verstaendnis der Sprache und ihrer idiomatischen Patterns ab.

Warum verwendet Go Functional Options statt Konstruktor-Ueberladung?

Go unterstuetzt weder optionale Parameter noch Methodenueberladung. Das Functional-Options-Pattern loest dieses Problem elegant: Es ermoeglicht beliebig erweiterbare Konfigurationen bei stabiler API. Neue Optionen koennen hinzugefuegt werden, ohne bestehende Aufrufer zu brechen. Standardwerte sind zentral definiert, und der aufrufende Code dokumentiert sich durch die benannten Option-Funktionen selbst.

Wie unterscheidet sich das Strategy Pattern in Go von Java?

In Java erfordert das Strategy Pattern eine explizite Interface-Deklaration (implements Processor). In Go werden Interfaces implizit erfuellt -- jeder Typ mit der passenden Methodensignatur implementiert das Interface automatisch. Das fuehrt zu loser Kopplung, da der implementierende Typ das Interface nicht kennen muss. In der Praxis erlaubt das auch, Interfaces nachtraeglich zu definieren, ohne bestehenden Code aendern zu muessen.

Wann sollte man Channels statt Callbacks fuer Event-Handling verwenden?

Channels sind die idiomatische Wahl, wenn Events zwischen Goroutines fliessen. Sie bieten eingebaute Synchronisation und koennen mit select kombiniert werden, um Timeouts, Cancellation und Multiplexing zu implementieren. Callbacks sind einfacher, wenn alles in einer Goroutine laeuft, fuehren aber bei konkurrierendem Zugriff zu Race Conditions, wenn nicht zusaetzlich synchronisiert wird.

Was ist der Unterschied zwischen Struct Embedding und Vererbung?

Struct Embedding ist Komposition mit syntaktischem Zucker. Der eingebettete Typ wird als anonymes Feld gespeichert, und seine Methoden werden promoted. Es gibt aber keine Polymorphie ueber den eingebetteten Typ: Ein User mit eingebettetem Timestamps kann nicht dort verwendet werden, wo ein Timestamps erwartet wird (es sei denn, der Zugriff erfolgt explizit ueber das eingebettete Feld). Vererbung in OOP-Sprachen erzeugt hingegen eine echte Subtyp-Beziehung. Go bevorzugt explizite Interfaces fuer Polymorphie und Embedding fuer Code-Wiederverwendung.

Fazit

Go Design Patterns unterscheiden sich fundamental von den klassischen Mustern objektorientierter Sprachen. Die Sprache setzt auf Komposition statt Vererbung, auf Interfaces statt abstrakte Klassen und auf Channels statt Callbacks. Die wichtigsten Erkenntnisse im Ueberblick:

• Functional Options loesen das Problem fehlender optionaler Parameter und Konstruktor-Ueberladung auf idiomatische Weise
• Strategy Pattern nutzt Go's implizite Interface-Erfuellung fuer maximale Entkopplung
• Factory Functions mit dem New-Praefix sind der Standard fuer validierte Objekterzeugung
• Observer mit Channels bietet goroutine-sichere Event-Verteilung ohne externe Abhaengigkeiten
• Middleware Pattern ermoeglicht stapelbare, wiederverwendbare HTTP-Handler-Logik
• Struct Embedding ersetzt Vererbung durch explizite Komposition mit Method Promotion

Wer diese sechs Patterns beherrscht und ihre Trade-offs artikulieren kann, ist fuer Go-Design-Pattern-Fragen im Interview bestens vorbereitet. Entscheidend ist nicht nur das Wissen um die Implementierung, sondern das Verstaendnis dafuer, warum Go diese Ansaetze gegenueber klassischen OOP-Patterns bevorzugt.