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

Reply via email to