Goでオブジェクト生成の返り値にinterfaceを使うとnil Pointer Receiverができないという話

タイトルそのままです。

package main

import (
    "fmt"
    "reflect"
)

type Fooer interface {
    Foo()
}

type Fooo struct{}

func (f *Fooo) Foo() {
    if f == nil {
        fmt.Println("nil!!")
    } else {
        fmt.Println("not nil!!")
    }
}

func newFooer() Fooer {
    return &Fooo{}
}

func bar(f Fooer) {
    f.Foo()
}

func main() {
    // 型を代入したあとnilを入れても型情報は消えない
    z := &Fooo{}
    fmt.Println(reflect.TypeOf(z)) // *main.Fooo
    z = nil
    fmt.Println(reflect.TypeOf(z)) // *main.Fooo
    z.Foo()                        // nil!!
    bar(z)                         // nil!!

    // 型情報を持ったnilを入れて、そのあとただのnilを入れても型情報は消えない
    y := (*Fooo)(nil)
    fmt.Println(reflect.TypeOf(y)) // *main.Fooo
    y = nil
    fmt.Println(reflect.TypeOf(y)) // *main.Fooo
    y.Foo()                        // nil!!
    bar(y)                         // nil!!

    // interfaceを返す関数から変数を代入したあとにnilを入れると型情報が消える
    x := newFooer()
    fmt.Println(reflect.TypeOf(x)) // *main.Fooo
    x = nil
    fmt.Println(reflect.TypeOf(x)) // <nil>
    // panicになる x.Foo()
    // panicになる bar(x)
}

発端はクリーンアーキテクチャをやろうと思いサンプルを探すと、この例のように生成系でinterfaceを返しているものが多いです。
依存関係の逆転をしたいので、接合部分をinterfaceにするというのは素直だと思いますが、Goでは微妙なところもありそうです。

Go言語のInterfaceの考え方、Accept interfaces,return structsに従ったほうが、大体は良さそう。

クリーンアーキテクチャをするならAccept interfaces,return structs に従って生成してからDIで渡すところでinterfaceを使うようにしたほうが良さそうです。