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
If your project exposes one interface and many implementations of it then
I'd consider it reasonable to have your interface in the top level package
and a subpackage for each implementation.
On Fri, Feb 17, 2017, 02:33 Luca Looz wrote:
> I'm starting now the project and i'm seeking advices on ho
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?
Il giorno venerdì 17 febbraio 2017 01:31:
Alternatively, you can leave them where they are and focus on the future so
that future implementation of the interface doesn't add to more garbage. It may
be possible to use fewer data types with configurable behavior.
--
You received this message because you are subscribed to the Google Group
It's a scraper and i'm already planning to drastically reduce
implementations by grouping them into common ones that can be configured
but i will not be able to do it for all of them
Il giorno giovedì 16 febbraio 2017 17:14:34 UTC+1, Henry ha scritto:
>
> It's difficult to recommend any specific
It's difficult to recommend any specific refactoring strategy without seeing
the actual codes. However, judging from your description where you have
hundreds of implementation for a single interface, it just feels wrong and I am
certain there is a way to simplify your codes. Instead of looking t
Can you be more specific?
Il giorno giovedì 16 febbraio 2017 14:36:19 UTC+1, Henry ha scritto:
>
> It seems like you could use some serious refactoring there, rather than
> merely organizing your files.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts"
