Interfejsy w Golang: niejawna implementacja, any i pułapka nil

Interfejs to zbiór metod

Typ interfejsu wymienia sygnatury metod. Każdy typ, który ma te metody, spełnia interfejs, bez żadnej deklaracji, która by to ogłaszała.

package main

import (
	"fmt"
	"math"
)

type Shape interface {
	Area() float64
	Perimeter() float64
}

type Rect struct{ W, H float64 }

func (r Rect) Area() float64      { return r.W * r.H }
func (r Rect) Perimeter() float64 { return 2 * (r.W + r.H) }

type Circle struct{ R float64 }

func (c Circle) Area() float64      { return math.Pi * c.R * c.R }
func (c Circle) Perimeter() float64 { return 2 * math.Pi * c.R }

func describe(s Shape) {
	fmt.Printf("%T area=%.2f perimeter=%.2f\n", s, s.Area(), s.Perimeter())
}

func main() {
	shapes := []Shape{Rect{3, 4}, Circle{1}}
	for _, s := range shapes {
		describe(s)
	}
}

Ani Rect, ani Circle nie wspomina o Shape. To niejawna implementacja, cecha definiująca interfejsy w Go. Oznacza, że możesz zdefiniować w swoim pakiecie interfejs, który typy z innych pakietów już spełniają, bez ruszania ich kodu.

Małe interfejsy z biblioteki standardowej

Kod w Go preferuje interfejsy z jedną lub dwiema metodami. Najważniejsze z nich:

Ponieważ io.Reader ma jedną metodę, implementują go dziesiątki typów, a każda funkcja przyjmująca io.Reader działa z nimi wszystkimi:

package main

import (
	"bytes"
	"fmt"
	"io"
	"strings"
)

func countBytes(r io.Reader) (int64, error) {
	return io.Copy(io.Discard, r)
}

type Temp float64

func (t Temp) String() string { return fmt.Sprintf("%.1f°C", float64(t)) }

func main() {
	n1, _ := countBytes(strings.NewReader("hello"))
	n2, _ := countBytes(bytes.NewBufferString("hello, gopher"))
	fmt.Println(n1, n2)

	var sb strings.Builder // an io.Writer
	fmt.Fprintf(&sb, "%d + %d = %d", 2, 2, 4)
	fmt.Println(sb.String())

	fmt.Println(Temp(21.5)) // fmt calls String()
}

Przysłowie Go mówi: „im większy interfejs, tym słabsza abstrakcja”. Większe interfejsy buduje się, łącząc małe: io.ReadWriter to Reader plus Writer, zapisany przez osadzenie jednego interfejsu w drugim.

any: pusty interfejs

interface{} nie ma metod, więc spełnia go każdy typ. Go 1.18 dodało any jako alias; oba są identyczne.

package main

import "fmt"

func main() {
	var v any

	v = 42
	fmt.Printf("%v %T\n", v, v)

	v = "text"
	fmt.Printf("%v %T\n", v, v)

	v = []int{1, 2}
	fmt.Printf("%v %T\n", v, v)

	items := []any{1, "two", 3.0, nil}
	fmt.Println(len(items))

	if s, ok := v.([]int); ok {
		fmt.Println("slice of len", len(s))
	}
}

Wartość any może przechowywać cokolwiek, ale niewiele da się z nią zrobić, dopóki nie odzyskasz konkretnego typu przez asercję typu albo type switch. Gdy zbiór typów jest znany, wybierz prawdziwy interfejs albo generyki. any pasuje do naprawdę dynamicznych danych, takich jak zdekodowany JSON o nieznanym kształcie, i do wypisywania.

Co zawiera wartość interfejsu

Wartość interfejsu to para: typ dynamiczny i wartość dynamiczna. var s Shape = Rect{3, 4} przechowuje typ Rect i kopię wartości. Wywołanie s.Area() wyszukuje metodę Rect w czasie działania.

Interfejs jest nil tylko wtedy, gdy obie części są puste. Ta reguła powoduje najbardziej mylący błąd w Go.

Pułapka interfejsu nil

Wskaźnik nil zapisany w interfejsie daje interfejs, który nie jest nil.

package main

import "fmt"

type MyError struct{ Msg string }

func (e *MyError) Error() string { return e.Msg }

func validate(ok bool) error {
	var err *MyError // nil pointer
	if !ok {
		err = &MyError{"invalid input"}
	}
	return err // BUG: returns a non-nil error even when ok is true
}

func validateFixed(ok bool) error {
	if !ok {
		return &MyError{"invalid input"}
	}
	return nil
}

func main() {
	err := validate(true)
	fmt.Println(err == nil) // false
	fmt.Printf("%T %v\n", err, err == (*MyError)(nil))

	fmt.Println(validateFixed(true) == nil) // true
}

Wynik:

false
*main.MyError true
true

validate(true) zwraca interfejs error z typem *MyError i wartością nil. Interfejs ma typ, więc nie jest równy nil, i wykonuje się gałąź if err != nil w kodzie wywołującym. Wywołanie tam err.Error() skończyłoby się paniką przy dostępie do pola nilowego odbiorcy.

Poprawka jest prosta: zadeklaruj zmienną jako error, a nie jako konkretny typ wskaźnikowy, albo zwracaj dosłowne nil na ścieżce sukcesu. Nigdy nie zwracaj konkretnego typu wskaźnika na błąd z funkcji, której wynikiem jest error. Ta sama pułapka dotyczy każdego interfejsu, nie tylko błędów.

Sprawdzanie, czy typ implementuje interfejs

Implementacja jest sprawdzana tam, gdzie wartość zostaje przypisana do interfejsu. Jeśli żaden kod jeszcze tego nie robi, pomyłka w sygnaturze metody przejdzie niezauważona. Puste przypisanie na poziomie pakietu sprawia, że sprawdzenie jest jawne:

var _ io.Writer = (*LogWriter)(nil)
var _ fmt.Stringer = Temp(0)

W czasie działania nic to nie kosztuje. Jeśli *LogWriter ma Write(p []byte) error zamiast Write(p []byte) (int, error), budowanie się nie powiedzie:

cannot use (*LogWriter)(nil) (value of type *LogWriter) as io.Writer value in variable declaration: *LogWriter does not implement io.Writer (wrong type for method Write)
		have Write([]byte) error
		want Write([]byte) (int, error)

Odbiorcy wskaźnikowi a interfejsy

Jeśli metoda ma odbiorcę wskaźnikowego, tę metodę ma tylko typ wskaźnikowy. *Counter spełnia dzięki niej interfejs, a Counter nie. Kompilator zgłasza Counter does not implement Incrementer (method Inc has pointer receiver). Zapisz w interfejsie &Counter{}. Strona o metodach wyjaśnia zbiory metod.

Przyjmuj interfejsy, zwracaj struktury

Popularna wskazówka w Go: funkcje powinny przyjmować parametry będące interfejsami i zwracać konkretne typy.

• Przyjmowanie interfejsu pozwala wywołującym przekazać wszystko, co pasuje, łącznie z atrapami w testach. Funkcja, która czyta dane, powinna przyjmować io.Reader, a nie *os.File.
• Zwracanie konkretnego typu pozwala wywołującym używać wszystkich jego metod i pól oraz omija pułapkę interfejsu nil. os.Open zwraca *os.File, a nie io.Reader.

Powiązany nawyk: definiuj interfejsy tam, gdzie są używane, a nie tam, gdzie są implementowane. Jeśli twój serwis potrzebuje czegoś, co potrafi wykonać Get(id) dla użytkownika, zadeklaruj jednometodowy interfejs w pakiecie serwisu, a pakiet bazy danych niech po prostu eksportuje swoją strukturę.

package main

import (
	"errors"
	"fmt"
)

// Declared by the consumer, with only what it needs.
type UserGetter interface {
	GetUser(id int) (string, error)
}

func greet(db UserGetter, id int) string {
	name, err := db.GetUser(id)
	if err != nil {
		return "hello, stranger"
	}
	return "hello, " + name
}

// A fake for tests or examples: no mocking library needed.
type fakeDB map[int]string

func (f fakeDB) GetUser(id int) (string, error) {
	if n, ok := f[id]; ok {
		return n, nil
	}
	return "", errors.New("not found")
}

func main() {
	db := fakeDB{1: "Ana"}
	fmt.Println(greet(db, 1))
	fmt.Println(greet(db, 2))
}

Porównywanie wartości interfejsów

Dwie wartości interfejsu są równe, gdy ich typy dynamiczne są identyczne, a wartości dynamiczne równe. Jeśli typ dynamiczny nie jest porównywalny (slice, mapa), == się kompiluje, ale w czasie działania wywołuje panikę: runtime error: comparing uncomparable type []int.

Częste błędy

• Zwracanie typowanego wskaźnika nil jako interfejsu. Zwracaj dosłowne nil.
• Interfejsy za wcześnie. Najpierw napisz konkretny typ. Dodaj interfejs, gdy potrzebuje go druga implementacja albo test.
• Wskaźnik na interfejs. *io.Reader prawie nigdy nie jest właściwy. Interfejs już przechowuje wskaźnik, gdy go w nim zapiszesz.
• Duże interfejsy. Interfejsy z dziesięcioma metodami trudno zaimplementować i trudno podrobić w testach. Podziel je.