Golang – Pull all the structs out???

2 points by brianvoe 3 years ago | 8 comments

Something I am dealing with at work right now is the idea of pulling all the main structs of our packages into a single package to alleviate(not get rid of) cyclical import issue.

The issue I have with this is that when we pull all of the main structs from there packages you disconnect the logic from data structs that us it. Plus remove certain core functionality like more advance logic that would go into a method that cant be simple getters and setters in that struct package.

The other issue I contend with is that in doing so it just doesn't "feel" like idiomatic Go. For the many years I have been using Go both core package and open source ones(big and small) and I just don't see many cases where packages completely pull their main structs out. I also try to think about what more advanced developers would do like Rob Pike(https://www.youtube.com/watch?v=PAAkCSZUG1c&t=568s), Brad Fitzpatrick, Russ Cox, I assume they wouldn't think this is a good idea. Presenting various example and quotes from core Go developers didn't seem to sway them.

Does anyone have experience in this area? Has anyone pulled their main structs out and have been better off for it? Has anyone pulled them out and then realized it was bad and moved them all back?

What are your thought?

orbz 3 years ago |

This is a horrible idea that will eventually make the situation of cyclical dependencies even worse.

Hitting cyclical dependencies is an indication that the code base is not being built in a composable fashion with layers depending on other layers. This is usually solved with more packages of more focused independent functionality rather than less packages of less functionality.

arinlen 3 years ago | |

> This is usually solved with more packages of more focused independent functionality rather than less packages of less functionality.

Also, dependency injection. It's possible to get rid of all dependencies if your code just refers to abstract interfaces and delegates the responsibility to provide concrete implementations to downstream dependencies.

brianvoe 3 years ago | |

Thanks for the reply. Do you feel this way too if external repos need this data as well? I advocated for the use of interfaces for these external packages to keep them self contained an not reliant on an external structs package for a few simple fields.

orbz 3 years ago | | |

Absolutely, having very focused packages helps from an external consumer perspective as well.

Interfaces can help if you have multiple things that all implement the same functionality or you need to mock out for testing, but often times people will create interface bloat for things that are only implemented by a single struct and there’s no benefit to testing.

daviddever23box 3 years ago |

It might be worth hiring an experienced Go developer, even as an independent contractor, to review your codebase as well as to help you lint your code.

metadat 3 years ago |

Program against interfaces instead of concrete classes (i.e. structs). The coupling needs to be loosened.

brianvoe 3 years ago | |

Agreed! Thanks.

metadat 3 years ago | | |

To be clear, I don't think anything should be pulled out. Likely needs a lot of re-working and thought given to clean up the dependency graph such that you have primarily abstract interfaces across logical boundaries.

Edit: Here's an example, anything along the lines of "clean domain-driven design" will hopefully be enlightening.

https://hackernoon.com/clean-domain-driven-design-in-10-minu...

Best wishes and good luck!