Thanks @Louki,
The names are absolutely made up and are just for the purpose of
demonstration.
The problem is the package state, one whole package to just hold a type.
On Tuesday, April 24, 2018 at 10:36:29 AM UTC+4:30, Louki Sumirniy wrote:
>
> The name could use some work, stutter is a no-no in Go. What kind of state
> does it hold? User profiles? MMO game world database? Is your scope too
> broad? I see that it looks like a geography database, so it would make more
> sense to call it 'geo' or something like this. Also, for such a database
> system there is waypoints, paths and regions as subtypes that I can think
> of off the top of my head. Or maybe 'location' is a better name for it.
> Will there be a history ledger also?
>
> I hope that helps you... it's just a namespace question really. The
> important thing about how to define it has to do with what will be done
> with it not what it is, as a matter of ontology. Object oriented design
> methodology tends to look at things like everything can be abstracted and
> in the real world, categories are containers, like 'car' is the general,
> 'engine', 'transmission', 'wheels', and inside engine is 'carb/injector'
> 'pistons' 'cams' 'ignition' inside ignition is ignition timing, throttle
> etc etc. If you follow a model of containers you will get clean boundaries
> between things, and the path from user to data will be much more clear.
>
> On Tuesday, 24 April 2018 08:49:45 UTC+3, 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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
