Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
Hands-On Dependency Injection in Go

You're reading from   Hands-On Dependency Injection in Go Develop clean Go code that is easier to read, maintain, and test

Arrow left icon
Product type Paperback
Published in Nov 2018
Publisher Packt
ISBN-13 9781789132762
Length 346 pages
Edition 1st Edition
Languages
Arrow right icon
Author (1):
Arrow left icon
Corey Scott Corey Scott
Author Profile Icon Corey Scott
Corey Scott
Arrow right icon
View More author details
Toc

Table of Contents (15) Chapters Close

Preface 1. Never Stop Aiming for Better 2. SOLID Design Principles for Go FREE CHAPTER 3. Coding for User Experience 4. Introduction to the ACME Registration Service 5. Dependency Injection with Monkey Patching 6. Dependency Injection with Constructor Injection 7. Dependency Injection with Method Injection 8. Dependency Injection by Config 9. Just-in-Time Dependency Injection 10. Off-the-Shelf Injection 11. Curb Your Enthusiasm 12. Reviewing Our Progress 13. Assessment 14. Other Books You May Enjoy

A quick word about idiomatic Go

Personally, I try to avoid using the term idiomatic Go but a Go book is arguably not complete without addressing it in some form. I avoid it because I have seen it too often used as a stick to beat people. Essentially, this is not idiomatic, therefore it's wrong and, by extension, I am idiomatic and therefore better than you. I believe that programming is a craft and, while a craft should have some form of consistency in its application, it should, as with all crafts, be flexible. After all, innovation is often found by bending or breaking the rules. 
So what does idiomatic Go mean to me?

I'll define it as loosely as I can:

  • Format your code with gofmt: Truly one less thing for us programmers to argue about. It's the official style, supported with official tools. Let's find something more substantive to argue about.
  • Read, apply, and regularly revisit the ideas in Effective Go (https://golang.org/doc/effective_go.html) and Code Review Comments (https://github.com/golang/go/wiki/CodeReviewComments): There is a huge amount of wisdom in these pages, so much so that it's perhaps impossible to glean it all from just one reading.
  • Aggressively apply the Unix philosophy: It state that we should design code that does a single thing, but to does it well and works well together well with other code.

While these three things are the minimum for me, there are a couple of other ideas that resonate:

  • Accepting interfaces and returning structs: While accepting interfaces leads to nicely decoupled code, the returning structs might strike you as a contradiction. I know they did with me at first. While outputting an interface might feel like it's more loosely coupled, it's not. Output can only be one thing—whatever you code it to be. Returning an interface is fine if that's what you need, but forcing yourself to do so just ends up with you writing more code.
  • Reasonable defaults: Since switching to Go, I've found many cases where I want to offer my user the ability to configure the module but such configuration is frequently not used. In other languages, this could lead to multiple constructors or seldom used parameters, but by applying this pattern we end up with a much cleaner API and less code to maintain.
lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime
Banner background image