Open arishlabroo opened 2 years ago
Factory upside:
Factory downside:
I understand why, for general consumption, there'd be some pushback. For your organization however, there are likely plenty of examples of usage, as well as coaching from the author's that reduce the importance of the intuition piece. In that context, you're less worried about wide spread adoption and more concerned about isolating bugs and the general debugging experience. Considering that, it makes sense that you'd make the tradeoff in favor of factories.
We got feedback that use of a factory function in go is not "idiomatic". I would like to use this issue to understand this more and gather feedback/alternatives.
To clarify, we don't "need" factories. Here is a pull request without a factory for the server, while still keeping the server testable and configurable. https://github.com/zillow/howwegoatzillow/pull/1/files
basically we added a
Configure()
method on the Server. And now you can simply doinstead of
couple of things that standout in the factory less approach.
1. Every service will need a new type to represent the application specific server.
func NewMyServer(server *server.Server, service *MyService) *MyServer
why cant you dofunc DoMyServerThings(server *server.Server, service *MyService) {
main
now responsible for getting the Server and MyService and then call this function before it starts serving?2. Ideally the server after creation is immutable.
With a factory, after you have created a
Server
, there is nothing you can do on the it other thanServe()
.With the
Configure()
method, imagine this scenarioWhat does the second Configure do?
error, based on what, a mtx and a boolean flag inside to server to prevent further configuration?
ignore? yeah, thats what
http.Server
does . Does it?Is this guaranteed to listen on 8080 🤔 ? What if the scheduler hasn't gotten to the ListenAndServer go routine yet 🤔
This is a BS scenario. absolutely not worth accounting for.
These two issues are in no means an attempt to demonstrate that we need Factories. I 100% agree that we don't "need" them.
I am more curious about whats wrong with using them 🤔 . (factoryOfFactory or other java jokes aside), and more importantly, what alternative approach would you recommend? (ps: none of our services have factories, we have never seen a need for them outside of couple of core packages)