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)

Chapter 3, Coding for User Experience

1. Why is the usability of code important?

Good UX is not nearly as apparent as bad UX. This is because when UX is good, it just works.

Typically, the more complicated, obfuscated, or unusual a piece code is, the harder it is to understand. The harder code is to follow, the harder it is to maintain or extend and the higher the chance of mistakes being made.

2. Who benefits the most from code with great UX?

As programmers, we are both the creators and greatest users of our code; it is, therefore, our colleagues and ourselves that benefit most.

 

3. How do you construct good UX?

The best UXes are intuitive and natural to their users. The key, therefore, is to try to think as your users do. Chances are that the code you write will make sense and hopefully be natural to you, but can you say the same for the rest of your team?

In this chapter...