Coming from Java I am having some difficulty with missing the
The project I currently joined has many files under a single package. One can claim that all the components are related to each other enough and it is fine. But since the files actually describe different components they have many unexported functions that they needlessly share.
It is also annying that there many unit tests and you can’t write a simple
setup function in a way it won’t be shared.
Maybe a better architecture would be mapping golang packages to something like classes?
So a package would have an interface file an implementation and maybe other files with unexported functions?
Or am I trying to force Java concepts too hard on go?
Make smaller packages in a nested structure such that the overlapping namespace wouldn’t be an issue anymore.
The existence of a
private keyword wouldn’t change your problem.
THIS -> “Or am I trying to force Java concepts too hard on go?”
I come from C++ and Python.
As I general rule when I start learning/use a new language/tool I try to avoid to think about “how to implement X using my knowledge of language Y”.
Each language has its own features and also way of thinking and design software.
So try to simplify the structure of your modules and… “Start thinking in Go”
Having smaller packages is often wise but creating a package just to house one or two functions is annoying.
If you have not already, I would advise studying the concepts of modules, internal packages, testing packages and (implicit) interfaces and inspecting the standard library.
But most importantly with Go just code and don’t worry too much about the structure and organization of your code in the initial stages. Go is a delight to refactor especially if you have good tests. Along with the comprehensive standard library and implicit interfaces this is the reason Go is a great prototyping language.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.