Book Image

Hands-On Dependency Injection in Go

By : Corey Scott
Book Image

Hands-On Dependency Injection in Go

By: Corey Scott

Overview of this book

Hands-On Dependency Injection in Go takes you on a journey, teaching you about refactoring existing code to adopt dependency injection (DI) using various methods available in Go. Of the six methods introduced in this book, some are conventional, such as constructor or method injection, and some unconventional, such as just-in-time or config injection. Each method is explained in detail, focusing on their strengths and weaknesses, and is followed with a step-by-step example of how to apply it. With plenty of examples, you will learn how to leverage DI to transform code into something simple and flexible. You will also discover how to generate and leverage the dependency graph to spot and eliminate issues. Throughout the book, you will learn to leverage DI in combination with test stubs and mocks to test otherwise tricky or impossible scenarios. Hands-On Dependency Injection in Go takes a pragmatic approach and focuses heavily on the code, user experience, and how to achieve long-term benefits through incremental changes. By the end of this book, you will have produced clean code that’s easy to test.
Table of Contents (15 chapters)

Optimizing for humans

In recent years, we have seen the rise of the term UX, which stands for user experience. At its core, UX is about usability—understanding the user and crafting interactions and interfaces to be more intuitive or more natural for them to use.

UX typically refers to customers, which makes sense—that is, after all, where the money is. However, we programmers are missing out on something rather significant. Let me ask you, who are the users of the code you write? Not the customers that use the software itself. The users of the code are your colleagues and the future version of you. Would you like to make their life easier? Put in a different way, would you rather spend your future trying to figure out the purpose of a piece of code or extending the system? That is where the money is. As programmers, we get paid to deliver features...