In addition to Kevin's excellent answer, I may as well add that you should
probably attempt to simplify your codes first. Maintaining hundreds
of implementation is a nightmare. You could probably convert those hundreds
of items into data and have only one implementation whose behavior changes
according to the data supplied. For example, consider a chef that knows
hundreds of recipes to prepare a meal. Instead of hardcoding those hundreds
of recipes, you should store those recipes into data and have a
Recipe object to translate the data into steps to prepare the food.
If you really can't think of any other ways to simplify your design, you
may organize your files per Kevin's suggestion. I would put my chef and his
recipes as follows:
chef/
- chef.go
- recipe_interface.go
recipes/
italian/
- food1.go
- food2.go
french/
- food1.go
- food2.go
internal/
constants/
- shared_private_constants.go
I hope this helps.
Henry
On Friday, February 17, 2017 at 3:33:17 PM UTC+7, Luca Looz wrote:
> I'm starting now the project and i'm seeking advices on how to organize
> packages. Should i use a separate package for each implementation to avoid
> visibility issues with constants and other global vars that are internal
> for only a single implementation?
>
>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
