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.
