Dependency Injection with Constructor Functions

What is Dependency Injection?

At its core, Dependency Injection is a design pattern where a component's dependencies (the other objects it needs to work) are "injected" from the outside, rather than being created internally. This inverts the control of dependency management, leading to more decoupled and modular code.

Given your experience in system design, you might recognize this as the core mechanism that enables patterns like Hexagonal Architecture (Ports and Adapters). The "ports" are our interfaces, and the "adapters" are our concrete implementations. DI is how we plug an adapter into a port.

To get a solid grasp of the concept and its benefits, let's start with a foundational article.

Constructor Injection: The Go Way

While other languages often rely on complex frameworks for DI, Go's philosophy favors explicitness and simplicity. The most idiomatic way to perform DI in Go is through Constructor Injection.

This involves:

1. Defining a struct that holds its dependencies as fields, typically using interface types.
2. Creating a "constructor" function (by convention, named New...) that accepts these dependencies as arguments and returns an initialized instance of the struct.

This approach makes a component's dependencies explicit in its constructor signature. There is no "magic" involved; it's just plain Go functions and types.

This video provides an excellent analogy and a clear code demonstration of this pattern.

Hands-On: Wiring up the simple-bank API Server

Now, let's apply this to our project. We'll create a basic APIServer struct that will eventually handle our REST API. This server will need to perform data operations, so it will depend on our Storage interface.

Step 1: Create the APIServer Struct and Constructor

First, let's create a new home for our API-related code.

1. Create a new directory: internal/api.
2. Inside internal/api, create a new file named server.go.

Now, add the following code to internal/api/server.go. This defines our server and its constructor, which uses dependency injection.

package api

import (
	"log"
	"simple-bank/internal/storage"
)

// APIServer handles HTTP requests for our banking service.
type APIServer struct {
	listenAddr string
	store      storage.Storage
}

// NewAPIServer creates a new APIServer instance with its dependencies.
func NewAPIServer(listenAddr string, store storage.Storage) *APIServer {
	return &APIServer{
		listenAddr: listenAddr,
		store:      store,
	}
}

// NOTE: We will add a Run() method and actual handlers in a future lesson.
// For now, we'll add a simple placeholder to confirm it's wired correctly.
func (s *APIServer) Start() {
	log.Printf("API server starting on %s", s.listenAddr)
	// HTTP server setup will go here later
}

Notice that NewAPIServer doesn't know or care what kind of storage it receives. It only cares that the provided store satisfies the storage.Storage interface contract.

Step 2: Wire the Dependencies in main.go

The main function is the composition root of our application. This is where we create our concrete dependencies and inject them into the components that need them.

Update your cmd/main.go file to look like this:

package main

import (
	"simple-bank/internal/api"
	"simple-bank/internal/storage"
)

func main() {
	// 1. Create the concrete dependency (the storage adapter)
	store := storage.NewMemoryStorage()

	// 2. Inject the dependency into the component that needs it (the API server)
	server := api.NewAPIServer(":8080", store)

	// 3. Start the application
	server.Start()
}

Let's break down this wiring process:

1. We call storage.NewMemoryStorage() to create a concrete instance of our in-memory repository.
2. We then pass this store instance to api.NewAPIServer. Since *MemoryStorage implements the storage.Storage interface, the Go compiler allows this assignment.
3. Finally, we call the Start method on the configured server.

Run the application from your terminal:

go run cmd/main.go

You should see the output: API server starting on :8080. This confirms that you have successfully created your dependencies and wired them together!

Compile-Time Compliance Checks: The Safety Net

In the previous lesson, we added the line var _ Storage = (*MemoryStorage)(nil). Now its importance becomes even clearer in the context of DI. This "interface guard" acts as a safety net. It guarantees at compile time that the object you intend to inject (*MemoryStorage) is actually compatible with the interface "slot" it's supposed to fit into (Storage).

This is a common and powerful pattern in Go. If you were to refactor your Storage interface and forget to update MemoryStorage, this check would cause a compile error right in storage/memory.go, pointing you directly to the problem, long before you even try to run main.go.

Let's see this pattern used in the context of creating a mock for testing, which is another prime use case for DI.

This simple line of code is your first line of defense in maintaining a correctly wired, interface-driven application. For a deeper dive, the article "Interface guards in Go" on Redowan's Reflections provides more context on this specific pattern.

The Payoff: Flexibility and Testability

Why go through all this trouble? The two primary benefits are flexibility and testability.

1. Flexibility: Because our APIServer depends on the Storage interface, not a concrete type, we can swap out the implementation with a single line change in main.go. When we build our PostgreSQL repository, changing our application to use it will be as simple as:

// In main.go...
// store := storage.NewMemoryStorage() // Old line
store := storage.NewPostgresStorage(connectionString) // New line!

server := api.NewAPIServer(":8080", store) // This line doesn't change

This is the ultimate payoff for your goal of having easily switchable databases. This video clip perfectly illustrates this "swap".

2. Testability: DI is the key to effective unit testing. When testing our APIServer's logic, we don't want to depend on a real database. Instead, we can inject a mock or our existing MemoryStorage to run tests quickly and in isolation.

We will explore this in depth in Module 4 when we write unit and integration tests.

Conclusion

In this lesson, you've mastered a foundational pattern for building robust Go applications. You have taken the separate components from our previous work—the interface and its implementation—and wired them together cleanly and explicitly.

Key Takeaways:

• Dependency Injection (DI) is a pattern for providing a component with its dependencies from an external source.
• Constructor Injection is the idiomatic Go approach, using New... functions that accept interfaces as arguments.
• The main function serves as the composition root, where all application components are created and wired together.
• DI is the key that unlocks flexibility (swapping implementations like MemoryStorage for PostgresStorage) and testability (injecting mocks in tests).
• Compile-time interface guards (var _ Interface = (*ConcreteType)(nil)) act as a crucial safety net to ensure your implementations always satisfy their contracts.

Next Up

We now have a solid, flexible foundation for our data layer. We've defined the contract, built an in-memory implementation, and wired it into our application. The next logical step is to create a persistent, production-ready storage backend.

In the next lesson, we will begin working with PostgreSQL. You will learn how to set up and configure a PostgreSQL connection pool using pgx/pgxpool, preparing the ground for our second implementation of the Storage interface.