Best practice to partially implement an interface

Question

What would be the go-way of partly providing a default implementation?

To illustrate, the following simple example of a toggle switch driver is the dead-end I ended with by following my OO intuition... Of course it does not compile (I know why) and I am not necessarily willing to do so. Any other solution better fitting into the go philosophy would be in fact even better to correctly understand the go-way for this common need.

---

The complete example can also be found at https://play.golang.org/p/MYED1PB-dS

Given the following interface:

type ToggleSwitch interface {
    TurnOn()
    TurnOff()
    IsOn() bool
    Toggle()
}

Toggle() is a good candidate to be provided a default implementation (ie, according to the current state, turn on or off the switch):

// The Toggle() method can already be defined using TurnOn, TurnOff() and IsOn().
type DefaultDriver struct {
}

// The following implementation would be fine for non-optimized cases:
func (d *DefaultDriver) Toggle() {
    state := d.IsOn()
    fmt.Println("generic toogle ->", state)
    if state {
        d.TurnOff()
    } else {
        d.TurnOn()
    }
}

And then an actual driver could use it or not:

// Example of an actual ToggleDriver which should fully implement the interface
// based on the default implementation or not.
// For example, if the toggle switch device has a bult-in toggle command, the
// Toggle() method could be optimized to directly use it.
type DummyDriver struct {
    *DefaultDriver // promote DefaultDriver methods
    state bool
}

func (d *DummyDriver) IsOn() bool {
    return d.state
}

func (d *DummyDriver) TurnOff() {
    d.state = false
}

func (d *DummyDriver) TurnOn() {
    d.state = false
}

// Uncomment me to optimize me...
//func (d *DummyDriver) Toggle() {
//  fmt.Println("specialized toogle ->", d.state)
//  d.state = !d.state
//}

Answer 1

Personnally, I would implement the Toggle, IsOn, TurnOn and TurnOff methods for the DefaultDriver type, so it would satisfy the ToggleSwitch interface.

Then, the DummyDriver type would embed the DefaultDriver type.

This way, you could implement the specialized methods for the DummyDriver type, as you desire.

The result would be something along these lines:

package main

import "fmt"

type ToggleSwitch interface {
    TurnOn()
    TurnOff()
    IsOn() bool
    Toggle()
}

type DefaultDriver struct {
    state bool
}

func (d *DefaultDriver) Toggle() {
    state := d.IsOn()
    fmt.Println("generic toogle ->", state)
    if state {
        d.TurnOff()
    } else {
        d.TurnOn()
    }
}

func (d *DefaultDriver) IsOn() bool {
    return d.state
}

func (d *DefaultDriver) TurnOff() {
    d.state = false
}

func (d *DefaultDriver) TurnOn() {
    d.state = true
}

type DummyDriver struct {
    DefaultDriver
    state bool
}

// Uncomment me to optimize me...
//func (d *DummyDriver) Toggle() {
//  fmt.Println("specialized toogle ->", d.state)
//  d.state = !d.state
//}

func main() {
    d := DummyDriver{state: false}
    d.Toggle()
    d.Toggle()
    d.Toggle()
}

https://play.golang.org/p/Xm-8A0xoRb

Answer 2

In my opinion what you're trying to do isn't very Go-like.

ToggleSwitch defines four methods that clearly work on some state. In order to provide an implementation for any of these methods, you also need to implement that state (even if that state's non-existent, e.g. by defining those methods as no-ops), but at that point, it simply doesn't make sense not to provide all those methods.

With Go-like type composition the embedded types should generally be "whole", complete and useful on their own. Methods provided by the embedded type only work on that field alone, there's no way to get to the "parent" or its methods.

If ToggleSwitch also had other methods that didn't deal with that state, then it'd make sense to provide only a partial implementation of the interface, but at that point an even better and much more idiomatic solution would be to define ToggleSwitch as a combination of two separate interfaces.

In other words, I don't think there's a "Go way" to provide a partial implementation of an interface (that's not composed of several interfaces), because it's idiomatic in Go to define interfaces that are as small as possible.