I. Adapter - Structural Pattern

The Adapter is a Structural Design Pattern that allows objects with incompatible interfaces to work together. It acts as a wrapper — taking an existing class and adapting it to a target interface that the client expects, without changing either the client or the original class.

The Adapter pattern is particularly useful when you want to avoid violating the Open/Closed Principle: instead of modifying an existing implementation to satisfy a new requirement, you simply write a new adapter that bridges the gap. The original code stays untouched; you only add.

Think of it like a power plug adapter — your laptop charger has a fixed connector, but you can travel anywhere in the world by carrying the right adapter. The charger doesn't change. The socket doesn't change. Only the adapter in the middle does the job.

II. Real-world Example

Imagine you're building a backend service that needs to make HTTP GET requests. At first, your team uses Fetch as the HTTP module. Later, a new requirement comes in to support Axios as an alternative — perhaps for certain environments or configurations.

Without the Adapter pattern, you'd need to rewrite the client code or introduce conditionals everywhere. With it, you define a single Http interface and create a separate adapter for each implementation. The client never needs to know which one is running underneath.

This scenario introduces the following components:

1. Http (interface): Defines the contract — a single Get(url string) (interface{}, error) method. Any HTTP module that wants to work with the client must satisfy this interface.

2. Fetch: An existing HTTP module with its own Get method. It's already doing its job — we don't touch it.

3. Axios: Another HTTP module with the same Get method signature, but a different internal implementation.

4. FetchAdapter: Wraps a *Fetch instance and implements the Http interface by delegating to Fetch.Get().

5. AxiosAdapter: Wraps a *Axios instance and implements the Http interface by delegating to Axios.Get().

6. Client: Accepts any Http interface and calls Get() — completely unaware of whether it's talking to Fetch or Axios underneath.

The class diagram for the above scenario:

III. Implementation

• Definition of the Http interface:

1package adapter
2
3type Http interface {
4	Get(url string) (interface{}, error)
5}

• Fetch — an existing HTTP module:

1package adapter
2
3import "fmt"
4
5type Fetch struct{}
6
7func (m *Fetch) Get(url string) (interface{}, error) {
8	fmt.Printf("Http Get with Fetch: %s\n", url)
9	return nil, nil
10}

• Axios — another HTTP module:

1package adapter
2
3import "fmt"
4
5type Axios struct{}
6
7func (m *Axios) Get(url string) (interface{}, error) {
8	fmt.Printf("Http Get with Axios: %s\n", url)
9	return nil, nil
10}

• FetchAdapter — adapts Fetch to the Http interface:

1package adapter
2
3type FetchAdapter struct {
4	Instance *Fetch
5}
6
7func (m *FetchAdapter) Get(url string) (interface{}, error) {
8	return m.Instance.Get(url)
9}

• AxiosAdapter — adapts Axios to the Http interface:

1package adapter
2
3type AxiosAdapter struct {
4	Instance *Axios
5}
6
7func (m *AxiosAdapter) Get(url string) (interface{}, error) {
8	return m.Instance.Get(url)
9}

• Client — uses only the Http interface:

1package adapter
2
3type Client struct{}
4
5func (c *Client) Get(http Http, url string) (interface{}, error) {
6	return http.Get(url)
7}

• Running the example:

1fmt.Println("*** Example Adapter ***")
2client := adapter.Client{}
3url := "https://example.com/api"
4
5fetchAdapter := &adapter.FetchAdapter{Instance: &adapter.Fetch{}}
6client.Get(fetchAdapter, url)
7
8axiosAdapter := &adapter.AxiosAdapter{Instance: &adapter.Axios{}}
9client.Get(axiosAdapter, url)
10fmt.Print("*** End of Adapter ***\n\n\n")

With the output:

1*** Example Adapter ***
2Http Get with Fetch: https://example.com/api
3Http Get with Axios: https://example.com/api
4*** End of Adapter ***

IV. Explain the example above

Let's trace what actually happens step by step.

1. Define the target interface

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

This is the target interface — the contract that the Client depends on. It doesn't care about Fetch or Axios at all. It only knows Http.

2. The existing modules — untouched

Fetch and Axios both have a Get method with the same signature. But they are not implementing Http directly — they are standalone structs with no knowledge of the interface. We never modify them.

3. The adapters bridge the gap

fetchAdapter := &FetchAdapter{Instance: &Fetch{}}

FetchAdapter holds a reference to a *Fetch instance and satisfies the Http interface by simply delegating:

1func (m *FetchAdapter) Get(url string) (interface{}, error) {
2	return m.Instance.Get(url)
3}

Same pattern for AxiosAdapter. The adapter is the thin wrapper that makes incompatible things compatible.

4. The client — zero changes when switching implementations

1client.Get(fetchAdapter, url)
2client.Get(axiosAdapter, url)

The Client.Get() method receives any value that satisfies Http. It calls http.Get(url) — and Go's interface dispatch routes to the correct underlying implementation automatically.

Log result:

1Http Get with Fetch: https://example.com/api
2Http Get with Axios: https://example.com/api

Summary

If tomorrow a third HTTP module appears — say HttpClient — you only need to write one new adapter struct. The Client, Fetch, and Axios remain completely unchanged. This is the Open/Closed Principle in action.

V. Conclusion

The Adapter pattern is one of the most practical patterns in day-to-day software development. Any time you have a stable client that must work with multiple interchangeable implementations — HTTP clients, loggers, storage backends, payment gateways — Adapter gives you a clean way to plug them in without coupling your business logic to any specific library.

The key insight is: don't modify, adapt. Keep your existing code stable, keep your interface clean, and let the adapter carry the translation cost.

That said, as with all patterns, don't reach for Adapter when a simple function or direct call is sufficient. The value only becomes clear when you genuinely need to support multiple implementations behind a shared contract.

Thank you for reading! 😊

VI. References

• Go Design Patterns (Mario Castro Contreras)

• Full source code: available here.