The ability of single-method interfaces in Go

The opposite day I used to be pondering on the prevalence of single-method interfaces (SMI) in Go, and what makes them so efficient and helpful. SMIs have confirmed to be a really profitable software program modeling instrument for Go programmers, and you discover them throughout Go code-bases.

I attempted to consider the basics, which introduced me to among the earliest roots of our commerce: useful programming and higher-order capabilities (HOF). I mentioned some examples of making use of higher-order capabilities in Go not too long ago.

This publish will describe how SMIs are a extra common and highly effective approach than HOFs. It makes the next claims:

1. SMIs can do no matter HOFs can
2. SMIs are extra common
3. SMIs are considerably extra verbose for easy instances

To start, let’s use the identical instance as earlier than.

The tree search instance utilizing SMIs

The earlier publish demonstrated a Go resolution utilizing higher-order capabilities for the tree search drawback described earlier. I encourage you to assessment the sooner posts to get probably the most out of this one.

Let’s now see how the identical process might be completed utilizing SMIs as an alternative of HOFs; the full code is on GitHub. Beginning with the kinds:

kind State int
kind States []State

// GoalDetector is an interface that wraps a single IsGoal methodology. IsGoal
// takes a state and determines whether or not it is a purpose state.
kind GoalDetector interface {
  IsGoal(s State) bool
}

// SuccessorGenerator is an interface that wraps a single Successors methodology.
// Successors returns the successors of a state.
kind SuccessorGenerator interface {
  Successors(s State) States
}

// Combiner is an interface that wraps a single Mix methodology. Mix
// determines the search technique by combining successors of the present state
// with all the opposite states right into a single listing of states.
kind Combiner interface {
  Mix(succ States, others States) States
}

These are the equal SMIs to the GoalP, Successors and Combiner operate sorts we’ve seen earlier than; the names are barely modified to be extra appropriate for interfaces and their strategies.

The tree search itself – utilizing these interfaces – is nearly equivalent to the earlier model:

func treeSearch(states States, gd GoalDetector, sg SuccessorGenerator, combiner Combiner) State {
  if len(states) == 0 {
    return -1
  }

  first := states[0]
  if gd.IsGoal(first) {
    return first
  } else {
    return treeSearch(combiner.Mix(sg.Successors(first), states[1:]), gd, sg, combiner)
  }
}

To implement BFS, we reuse prependOthers from the earlier publish (it stays equivalent):

And once more, appendOthers and implementing DFS:

func bfsTreeSearch(begin State, gd GoalDetector, sg SuccessorGenerator) State {
  return treeSearch(States{begin}, gd, sg, CombineFunc(prependOthers))
}

What’s CombineFunc? Since prependOthers is a operate – whereas treeSearch takes interfaces – we’d like an adapter kind:

kind CombineFunc func(States, States) States

func (f CombineFunc) Mix(succ States, others States) States {
  return f(succ, others)
}

You probably have a little bit of Go expertise already, this will appear acquainted. It’s precisely the identical breed of adapter as http.HandlerFunc. Sadly, right now a Go operate can’t be assigned to a SMI with a suitable methodology signature, so these adapters are required (see the Appendix for extra particulars).