I. Decorator — Structural Pattern

The Decorator pattern is a structural design pattern that lets you attach new behaviors to objects by wrapping them inside decorator objects that share the same interface.

Instead of extending a class through inheritance, Decorator uses composition — a decorator wraps an existing object and adds behavior before or after delegating to it. Because decorators implement the same interface as the object they wrap, the client code never knows the difference.

Key properties:

• Same interface: decorators implement the same interface as the component they wrap

• Composable: decorators can be stacked — wrap a decorator inside another decorator

• Runtime flexibility: behaviors can be added or removed at runtime by choosing which decorators to apply

• Open/Closed Principle: add new behaviors without modifying existing code

Use Decorator when:

• You want to add responsibilities to objects without subclassing

• You need to combine behaviors in different ways at runtime

• Inheritance would produce an explosion of subclasses for every combination

II. Real-world Example

An HTTP client that needs logging and retry capabilities:

1. The core Http interface defines a single method: Get(url string) (interface{}, error)

2. FetchAdapter is the concrete implementation — it actually performs the HTTP request

3. LoggingDecorator wraps any Http and logs requests before and after

4. RetryDecorator wraps any Http and retries on failure up to N times

5. Decorators can be chained: RetryDecorator → LoggingDecorator → FetchAdapter

6. The client just calls .Get() on the outermost decorator — unaware of the chain

III. Implementation

http.go — the shared interface (reused from adapter package)

1package decorator
2
3import adapter "github.com/structural-patterns/adapter"
4
5type Http = adapter.Http

The Http interface from the adapter package:

1type Http interface {
2    Get(url string) (interface{}, error)
3}

logging_decorator.go — adds logging around any Http call

1package decorator
2
3import "fmt"
4
5type LoggingDecorator struct {
6    Inner Http
7}
8
9func (d *LoggingDecorator) Get(url string) (interface{}, error) {
10    fmt.Printf("Requesting %s\n", url)
11    response, err := d.Inner.Get(url)
12    if err != nil {
13        fmt.Printf("Request failed: %v\n", err)
14        return nil, err
15    }
16    fmt.Printf("Request succeeded: %s\n", url)
17    return response, nil
18}

retry_decorator.go — retries on failure up to N times

1package decorator
2
3import "time"
4
5type RetryDecorator struct {
6    Inner   Http
7    Retries int
8}
9
10func (d *RetryDecorator) Get(url string) (interface{}, error) {
11    var lastErr error
12    attempts := d.Retries + 1
13
14    for i := 0; i < attempts; i++ {
15        response, err := d.Inner.Get(url)
16        if err == nil {
17            return response, nil
18        }
19        lastErr = err
20        time.Sleep(time.Millisecond)
21    }
22
23    return nil, lastErr
24}

IV. Explain the example above

Let's trace through chaining both decorators:

1base    := &FetchAdapter{Instance: &Fetch{}}
2logged  := &LoggingDecorator{Inner: base}
3retried := &RetryDecorator{Inner: logged, Retries: 3}
4
5retried.Get("https://example.com")

Output (success case):

1Requesting https://example.com
2Http Get with Fetch: https://example.com
3Request succeeded: https://example.com

Step by step:

1. retried.Get("https://example.com") — RetryDecorator starts attempt 1 of 4

2. It calls logged.Get("https://example.com") — delegates to its Inner

3. LoggingDecorator logs "Requesting https://example.com", then calls base.Get()

4. FetchAdapter performs the actual request, prints "Http Get with Fetch: ..."

5. No error → LoggingDecorator logs "Request succeeded" and returns

6. RetryDecorator receives success on first attempt — no retry needed

Output (failure + retry case):

1Requesting https://broken-url.com
2Request failed: connection refused
3Requesting https://broken-url.com
4Request failed: connection refused
5... (up to Retries+1 times)

Each retry goes through the full decorator chain again — logging each attempt. You can also use each decorator independently:

1// Only logging, no retry
2client := &LoggingDecorator{Inner: &FetchAdapter{Instance: &Fetch{}}}
3client.Get("https://example.com")
4
5// Only retry, no logging
6client2 := &RetryDecorator{Inner: &FetchAdapter{Instance: &Fetch{}}, Retries: 2}
7client2.Get("https://example.com")

The key insight: decorators are interchangeable with the objects they decorate — both implement Http. This is what makes chaining possible. You can build any combination at runtime without changing a single struct definition.

V. Conclusion

The Decorator pattern solves the combinatorial explosion problem elegantly. Instead of creating LoggingFetchAdapter, RetryFetchAdapter, LoggingRetryFetchAdapter as separate classes, you compose them dynamically.

Trade-offs:

• Good fit: adding optional, composable behaviors to objects (logging, caching, retry, auth, rate-limiting); when inheritance would create too many subclasses; when behaviors need to be toggled at runtime

• Poor fit: when the order of decoration matters but is hard to reason about; deeply nested chains can make debugging harder — a stack trace through 5 decorators is less obvious than a single class

No pattern is universally superior. Use Decorator when you need flexible, composable behavior without touching existing code.

VI. References

• Go Design Patterns — Mario Castro Contreras

• Source code on GitHub