I. Facade — Structural Pattern

The Facade pattern is a structural design pattern that provides a simplified interface to a complex subsystem. It doesn't add new functionality — it hides complexity behind a clean, easy-to-use API.

The name comes from architecture: a building's facade is the front face that visitors see, hiding all the internal structure behind it. Similarly, a Facade class is what the client interacts with, while the complexity of the underlying subsystem is tucked away.

Key properties:

• Simplified interface: expose only what the client needs, hide what they don't

• Loose coupling: the client depends on the Facade, not on the individual subsystem classes

• Doesn't replace the subsystem — advanced users can still access it directly

• Single entry point: one place to orchestrate complex multi-step operations

Use Facade when:

• A subsystem is complex and clients only need a subset of its capabilities

• You want to layer your system with a clean boundary between tiers

• You want to reduce dependencies on internal implementation details

II. Real-world Example

A file storage system built on top of the Composite pattern:

1. The underlying subsystem uses composite.Folder and composite.File — powerful but verbose to use directly

2. StorageFacade wraps this complexity behind two simple methods: SaveFile() and ListAll()

3. SaveFile("/docs", "readme.md") internally creates folders if they don't exist, normalizes paths, and appends the file to the right folder — all hidden from the client

4. ListAll() delegates to root.Print() which uses Composite's recursive tree printing

5. The client never touches composite.Folder or composite.File directly

III. Implementation

storage_facade.go — the facade

1package facade
2
3import (
4	"fmt"
5	"strings"
6
7	composite "github.com/structural-patterns/composite"
8)
9
10type StorageFacade struct {
11	root    *composite.Folder
12	folders map[string]*composite.Folder
13}
14
15func NewStorageFacade(rootName string) *StorageFacade {
16	root := &composite.Folder{}
17	root.SetName(rootName)
18	return &StorageFacade{
19		root:    root,
20		folders: map[string]*composite.Folder{"/": root},
21	}
22}
23
24func (s *StorageFacade) SaveFile(folderPath string, fileName string) {
25	folder := s.ensureFolder(folderPath)
26	file := &composite.File{}
27	file.SetName(fileName)
28	folder.Add(file)
29}
30
31func (s *StorageFacade) ListAll() {
32	s.root.Print()
33}
34
35func (s *StorageFacade) Summary() string {
36	return fmt.Sprintf("Storage root: %s", s.root.GetName())
37}
38
39func (s *StorageFacade) ensureFolder(folderPath string) *composite.Folder {
40	normalized := normalizePath(folderPath)
41	if folder, ok := s.folders[normalized]; ok {
42		return folder
43	}
44
45	segments := strings.Split(strings.Trim(normalized, "/"), "/")
46	currentPath := "/"
47	current := s.root
48
49	for _, segment := range segments {
50		currentPath = currentPath + segment + "/"
51		if folder, ok := s.folders[currentPath]; ok {
52			current = folder
53			continue
54		}
55		folder := &composite.Folder{}
56		folder.SetName(segment)
57		current.Add(folder)
58		s.folders[currentPath] = folder
59		current = folder
60	}
61
62	return current
63}
64
65func normalizePath(folderPath string) string {
66	if folderPath == "" || folderPath == "/" {
67		return "/"
68	}
69	path := folderPath
70	if !strings.HasPrefix(path, "/") {
71		path = "/" + path
72	}
73	if !strings.HasSuffix(path, "/") {
74		path = path + "/"
75	}
76	return path
77}

IV. Explain the example above

Let's trace through a concrete usage:

1s := NewStorageFacade("root")
2s.SaveFile("/docs", "readme.md")
3s.SaveFile("/docs", "changelog.md")
4s.SaveFile("/src", "main.go")
5s.ListAll()

Output:

1root
2|--docs
3   |--readme.md
4   |--changelog.md
5|--src
6   |--main.go

Step by step:

1. NewStorageFacade("root") — creates the root Folder and seeds the folders map with "/": root

2. SaveFile("/docs", "readme.md") — calls ensureFolder("/docs/")
• /docs/ not in map → creates a new Folder{name: "docs"}, adds it to root, caches it
• Creates File{name: "readme.md"} and calls folder.Add(file)

3. SaveFile("/docs", "changelog.md") — calls ensureFolder("/docs/") again
• /docs/ already in map → returns cached folder directly, no new folder created
• Adds changelog.md to the same docs folder

4. SaveFile("/src", "main.go") — same flow, creates src folder and adds main.go

5. ListAll() — calls root.Print() which uses the Composite pattern to recursively render the tree

The client wrote 4 lines. Behind the scenes: path normalization, map lookups, folder creation, Composite tree assembly, recursive printing — all handled by the Facade.

You can also use ensureFolder for deeply nested paths:

1s.SaveFile("/src/handlers", "user.go")
2// creates: root → src → handlers → user.go
3// segments: ["src", "handlers"] — walks and creates each level

V. Conclusion

The Facade pattern is one of the most practical patterns in everyday software — you've almost certainly used it without naming it. Any time you create a service layer that wraps a complex repository, ORM, or third-party SDK behind clean methods, you're building a Facade.

Trade-offs:

• Good fit: complex subsystems with many moving parts; layered architecture where you want a clean API boundary; reducing client coupling to internal implementation

• Poor fit: when clients genuinely need fine-grained control over the subsystem — the Facade becomes a bottleneck; over-simplified Facades can hide information that callers actually need

One important note: Facade doesn't prevent direct access to the subsystem. It's a convenience, not a lock. Advanced clients can still use composite.Folder directly when they need to.

No pattern is universally superior. Use Facade when simplifying the interface genuinely reduces cognitive load for your callers.

VI. References

• Go Design Patterns — Mario Castro Contreras

• Source code on GitHub