@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.
