Assume the state is the config struct and each implementation is reading it
from s different file type (yaml, toml, hlc, json, etc).
On Friday, April 27, 2018 at 4:45:33 AM UTC+4:30, Jake Montgomery wrote:
>
> The example gives me a better understanding of what you are doing, though
> still not much understanding as to *why *you are doing it this way.
> Usually, if I feel that code has a "smell" in Go, there is a way to rethink
> the basic design resulting more "natural" code. But without a full
> understanding of the real situation, it is impossible to say if that
> applies here. But lets assume for now that you must have multiple packages
> that all contain functions that return a common struct.
>
>
>> But I do not like:
>>
>>
>> 1. Having a package just to hold a single type,
>>
>> Personally, I don't see anything inherently wrong with this. If you *must
> *multiple packages that all need the type, then it should be in a package
> separate from those. In many cases there would be functions that could also
> go in package `state`, but if not, then that's ok too.
>
> 2. The consumer package is accepting a concrete type and depends on it -
>> seems this one can not be avoided since there is nothing like structural
>> typing for structs in Go.
>>
>
> Your example does feel a bit awkward, but, again, I don't have enough
> information on what is really being achieved to suggest a completely
> different model.
>
> But I will take a shot in the dark. Think interfaces? Perhaps the
> state.State type returned by Clone() could be an interface? This does not
> solve the problem of having to define the interface in a separate package,
> and I would only use an interface if there was a compelling reason to do
> so.
>
> Taking a further leap,why "Clone()" at all? What do you do with state.State
> in package consumer? Does it have to be a struct for some reason? If you
> could define a set of functionality that a consumer needs from state.State,
> you could then have Concrete1, Concrete2, and Concrete3 all implement
> that functionality. Then consumer can just use them directly as
> interfaces ... or perhaps that is using them indirectly. Anyway, I hope
> that is somewhat comprehensible.
>
> Good Luck
> - Jake
>
> On Tuesday, April 24, 2018 at 1:49:45 AM UTC-4, Kaveh Shahbazian wrote:
>>
>> @Jake @Bryan Thanks!
>>
>> Current solution I use:
>>
>> A package that holds the shared data type State:
>>
>> package state
>>
>> type State struct {
>> Latitude float64
>> Longitude float64
>> Mark string
>> Name string
>> // ...
>> }
>>
>> Three packages with different implementations and algorithms:
>>
>> package concrete1
>>
>> import (
>> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
>> )
>>
>> type Concrete1 struct{}
>>
>> func (c *Concrete1) Clone() (*state.State, error) { panic("N/A") }
>>
>> And:
>>
>> package concrete2
>>
>> import (
>> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
>> )
>>
>> type Concrete2 struct{}
>>
>> func (c *Concrete2) Clone() (*state.State, error) { panic("N/A") }
>>
>> And:
>>
>> package concrete3
>>
>> import (
>> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
>> )
>>
>> type Concrete3 struct{}
>>
>> func (c *Concrete3) Clone() (*state.State, error) { panic("N/A") }
>>
>> And the consumer package, which will be given a concrete implementation
>> based on some logic (this is where "Accepting interfaces" is happening):
>>
>> package consumer
>>
>> import (
>> "gitlab.com/dc0d/gist/2018/Q1/draft/cmd/draft/state"
>> )
>>
>> func Use(cln cloner) {}
>>
>> type cloner interface {
>> Clone() (*state.State, error)
>> }
>>
>> The part in question is the *state.State data type. This is the best I
>> could come up with.
>>
>> But I do not like:
>>
>>
>> 1. Having a package just to hold a single type,
>> 2. The consumer package is accepting a concrete type and depends on
>> it - seems this one can not be avoided since there is nothing like
>> structural typing for structs in Go.
>>
>>
>> There might be a better way to do this.
>>
>
--
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.
