Elevator Pitch
Many Gophers, came to Go from other languages. Often those are OO languages like Java or C#. Unfortunately, the patterns and idioms we all learned there can be anti-patterns in Go. In this talk we will explore those patterns and how to adjust them to help us be better Gophers.
Description
Overview
Many Gophers, maybe even most of us, came to Go from other languages. Often those were OO languages like C++, Java, or C#. That OOP world is filled with 40 years of patterns and idioms and people who wanted to become “experts” in those languages spent a lot of time learning those patterns and committing them to mental muscle memory.
It’s likely that most of us have read the Gang of Four Design Patterns book. I think it’s actually assigned reading at some universities! There’s also the sage wisdom of Uncle Bob Martin. Others are out there, but you get the picture. The gotcha, though, is that those sources are all rooted in Object Oriented Design with its emphasis on classes, inheritance, virtual methods, and such. We’re all Gophers now, though, and Go is not really an OO language.
In this talk, we will take a tour around some common constructs, patterns, and idioms from Object Oriented Programming and explore how to translate them to idiomatic Go while avoiding the traps and pitfalls that come from directly translating existing C++/Java/C# code.
Outline
Introduction - 2 minutes
Talk about myself, my background, and why it matters that Gophers avoid simply replicating patterns and practices from OO languages.
Background and History of Object-Oriented Design - 5 minutes
Overview of what Object Oriented Design means to me, why it’s been successful, and how it’s affected my own career. Call out things like SOLID and Clean Architecture.
OOP Patterns and Idioms, But In Go - 15 minutes
Discuss how Go’s type system allows for an OO style, but in practice it doesn’t work in the same way
Details to include (among others):
- Embedding is not inheritance
- There is no virtual method dispatch
- Different philosophy on encapsulation (no public/protected/private)
- Packages, not classes, are the unit of code design
Tour of well-known OOP patterns and idioms, how not to apply them in Go, then how to adjust them to fit into idiomatic Go.
Examples including, but not limited to:
- Declaring interfaces as “abstract classes”
- Highlight how declaring interfaces as provider abstractions leads to unwanted coupling.
- Demonstrate how declaring interfaces at the consumer and relying on Go’s implicit interface satisfaction breaks that coupling.
- Breaking interdependency by refactoring to a third “shared” component
- A common strategy in OOP for decoupling components is to move the common code and declarations into a third “shared” component.
- Demonstrate how A little copying is better than a little dependency.
- Clean/Onion/Hexagonal Architecture
- Many OOP developers have come to automatically reach for the documented structural patterns like Bob Martin’s Clean Architecture, which is an adaptation of Hexagonal Architecture (itself a new take on Ports and Adapters)
- Demonstrate how Gophers can follow the ideas behind those structure patterns without adhering
to the naming conventions typically used in other languages. A “domain” package doesn’t actually
have to be named
domain!
- SOLID
- The 5 concepts called out in this acronym are practically gospel in the OO community. They are are all good ideas, but most of the examples you find when you search are fully couched in OOP implementation patterns.
- Demonstrate how each one can be implemented using idiomatic Go.
Note: I could easily expand this list to a dozen or more examples to fill the longer 45-minute tutorial
Conclusion - 2 minutes
With Object Oriented Programming dominating the industry for many years, many of us came to Go with a lot of our neural pathways wired to patterns and idioms from that world. While Go certainly supports writing in an object-oriented style, it is not really an OO language at it’s core. By comparing and contrasting these OOP staples with equivalent Go, we Gophers will be able to apply all of that past knowledge and experience while still writing idiomatic Go. Similarly, there’s definitely something to be said for learning from our predecessors and new engineers who started their journey in Go will get exposure to this rich history of software design and be able to apply those lessons of the past to their own projects.
Notes
After almost 7 years, I consider myself a veteran Go developer. Above and beyond that, though, I am a journeyman who has written code in COBOL, C++, Java, Visual Basic, C#, Javascript, TypeScript, Python, and now Go across 24 years and 5 different industries. In that time, I’ve written a ton of code and done everything from maintenance-level grunt work resolving Y2K bugs to designing, implementing, and deploying a greenfield distributed system used by tens of thousands of nurses daily to today being responsible for dozens of low-level Go libraries that support a wide range of customer-facing products.
I look forward to sharing this talk with my fellow Gophers because I feel it’s important that we all write our Go “in Go” and not just regurgitate the patterns we learned in our past lives writing Java, C#, etc. When I switched from C# to Go in early 2016 I made many of these “mistakes” myself so I can give a first-hand account of how things can appear to work at first but actually be very very wrong.