Decorator

Intent

Attaches new behaviours to objects by placing them inside wrapper objects that share the same interface.

Problem

Users want notifications by email, SMS and Slack in any combination. Subclassing every combination explodes.

Solution

Wrap the base notifier in decorators. Each adds its behaviour and delegates to the wrapped object.

Real-world analogy

Structure

Hover or tap a numbered role to highlight it in the diagram.

1. 1Component — Component declares the interface shared by wrappers and wrapped objects.
2. 2ConcreteComponent — Concrete Component is the object being wrapped; it defines the basic behaviour.
3. 3BaseDecorator — Base Decorator holds a reference to a wrapped Component and delegates all work to it.
4. 4ConcreteDecorator — Concrete Decorators add behaviour before or after calling the parent method.
5. 5Client — Client wraps components in as many layers as it needs.

Try it

Code example

// HTTP middleware is Go's everyday Decorator.
func Logging(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		start := time.Now()
		next.ServeHTTP(w, r)
		log.Printf("%s %s %v", r.Method, r.URL.Path, time.Since(start))
	})
}

// http.Handle("/", Logging(myHandler))

Applicability

How to implement

1. Make sure the domain can be a primary component with optional layers
2. Define a component interface
3. Create a concrete component
4. Create a base decorator holding a wrapped component and delegating to it
5. Create concrete decorators that add behaviour before or after delegating
6. Let the client compose decorators

Pros and cons

Relations with other patterns

Check yourself