How I Ended Up Creating a Dependency Injector, the Journey from PHP to Golang
Listen to the Blog and Follow Along with the Transcript
Transitioning from PHP to Golang has been an eye-opening experience. In PHP, dependency injection (DI) is widely used, especially with frameworks like Symfony and Laravel. However, when I started working with Golang, I realized that while DI exists, it is not as commonly used. This made me wonder: Why is dependency injection so popular in PHP but not in Golang?
Why Dependency Injection is Popular in PHP
PHP is a dynamically typed, interpreted language that is heavily object-oriented. Frameworks like Symfony and Laravel follow the SOLID principles, encouraging the use of dependency injection to achieve:
- Better maintainability – Injecting dependencies makes it easy to swap implementations without modifying the dependent classes.
- Testability – Mocking dependencies is simpler, making unit testing easier.
- Decoupling – Reduces tight coupling between classes, leading to a more modular design.
- PSR Standards – The PHP-FIG group introduced PSR-11 (Container Interface), which provides a standard way for dependency containers to work.
Why Golang Doesn't Emphasize Dependency Injection
Golang takes a different approach:
- Minimalist and explicit philosophy – Golang prefers explicit over implicit, avoiding magic.
- No built-in OOP system – While Golang has interfaces and structs, it does not have class-based inheritance like PHP.
- Dependency injection is done manually – Since Golang uses composition over inheritance, dependencies are often passed directly in constructors.
- Static typing with compilation – Reflection is more limited and less performant compared to dynamically typed languages.
Some references discussing DI in Golang vs PHP:
What is Autowiring?
Autowiring is a feature commonly found in PHP DI containers where dependencies are automatically resolved based on type hints. It removes the need for manual configuration.
Pros of Autowiring:
- Reduces boilerplate code.
- Makes dependency management easier.
- Works well with reflection-based frameworks.
Cons of Autowiring:
- Can introduce hidden dependencies, making debugging harder.
- Performance overhead due to runtime reflection.
- Less explicit, which can be problematic in large projects.
The Motivation Behind My Dependency Injector
While exploring Golang DI solutions, I wanted something that felt familiar to my PHP background. However, I couldn't find an implementation that provided the same experience. So, I thought: Why not build my own? 🚀
I aimed to:
- Introduce constructor-based dependency resolution.
- Support autowiring to minimize manual dependency configuration.
- Follow PSR-like standards where possible.
This was more challenging than PHP due to Golang’s:
- Lack of runtime type information.
- Limited reflection capabilities.
- Compiler enforcing strict type checks.
But hey, I love a good challenge! 💪
How It Works
Below is an overview of my dependency injection container, godi.
Dependency Injection in Golang
Creating the Dependency Container
container := godi.New()
Constructor-based Dependency Resolution
func (t *yourStruct) Construct(param yourInterface) {}
Registering Dependencies
container.Set("TestInterface", NewTest2())
Resolving Dependencies
test := NewTest()
_, err := container.Get(test)
if err != nil {
fmt.Println(err)
}
test.DoWhatYouWant()
Autowiring
type exampleMultipleImpl struct {
Dependency1 exampleMultipleDepInterface `di:"autowire"`
Dependency2 exampleMultipleDepInterface `di:"autowire"`
Dependency3 exampleMultipleDepInterface `di:"autowire"`
}
Managing Dependencies
Adding a Single Dependency
container := godi.New()
container.Set("TestInterface", NewTest2())
Retrieving a Single Dependency
dependency, err := container.GetDependency("dependencyInterfaceName2")
Adding Multiple Dependencies
dependencies := map[string]interface{}{
"dependencyInterfaceName1": NewDependency1(),
"dependencyInterfaceName2": NewDependency2(),
"dependencyInterfaceName3": NewDependency3(),
}
container.Build(dependencies)
Calling Functions with Resolved Dependencies
result, err := container.Call(TestFunc)
func TestFunc(d1 dependencyInterfaceName1, d2 dependencyInterfaceName2, d3 dependencyInterfaceName3) {}
Custom Values in Function Calls
result, err := container.Call(TestFunc, 55, "Hello")
func TestFunc(intValue int, stringValue string, d1 dependencyInterfaceName1, d2 dependencyInterfaceName2, d3 dependencyInterfaceName3) {}
Non-Singleton Resolution
container.Set("exampleInterface", callerFunc)
func callerFunc() interface{} {
return Your()
}
Flushing Dependencies
container.Flush()
Deleting a Single Dependency
container.Delete("dependencyInterfaceName2")
Counting Dependencies
count := container.Count()
fmt.Println(count)
Is This Useful? Let’s Discuss!
So, that’s my journey in creating a Golang DI container with autowiring. It was a fun challenge, and I’d love to hear your thoughts:
- Do you think DI is useful in Golang?
- Would you use autowiring, or do you prefer manual dependency injection?
- What other features would you like to see?
Let’s start the discussion in the comments! 🚀
