This is an automated archive.
The original was posted on /r/golang by /u/kingindanord on 2023-08-08 09:21:25+00:00.
I’ve recently dived back into a side project — a CLI tool. While trying to maintain best practices and incorporate unit tests, I’ve found myself gravitating towards a certain design pattern. An example of this pattern can be found in HashiCorp’s Consul code
In the code, there’s:
- A Registry interface.
- A Registration struct.
- A concrete TypeRegistry struct.
- And a factory function, NewRegistry(), that returns the Registry interface.
From my research, this looks like a blend of the Factory Pattern and the Dependency Inversion Principle (a pillar of the SOLID principles). However, I could be mistaken.
I’m wrestling with truly internalizing this pattern. Specifically, I’m struggling with discerning when it’s apt to use it, how to effectively implement it, and when it might be overkill.
My question is two-fold:
Beyond simply reading about these design patterns and analyzing projects that employ them, are there any exercises or methodologies you’d recommend to deepen my understanding?
A more fundamental question: Does this pattern, which feels reminiscent of OOP paradigms, feel too “object-oriented” for idiomatic Go? I’ve often heard Go isn’t a fan of classic OOP.
Any insights or advice would be greatly appreciated!