Interface — kontrak yang implisit

Interface Go dipenuhi secara implisit: sebuah tipe tidak perlu tahu interface apa pun yang ia penuhi. Konsekuensinya, interface dideklarasikan di sisi yang memakai, bukan di sisi yang menyediakan.

Implisit, dan kenapa itu penting

// Di pustaka standar:
type Writer interface {
	Write(p []byte) (n int, err error)
}

// Tipe apa pun yang punya method itu — TANPA mendaftar ke mana pun —
// bisa dipakai di mana Writer diminta.
type PenghitungByte struct{ n int64 }

func (p *PenghitungByte) Write(b []byte) (int, error) {
	p.n += int64(len(b))
	return len(b), nil
}

var w io.Writer = &PenghitungByte{}   // sah

Karena tidak ada deklarasi implements, kamu bisa membuat tipe milik pustaka pihak ketiga memenuhi interface yang kamu definisikan hari ini — tanpa menyentuh kode mereka. Ini yang membuat tes di Go jarang butuh kerangka mocking.

Aturan terpenting: interface milik pemakai

// internal/pesanan/layanan.go — PEMAKAI mendeklarasikan kebutuhannya.
// Perhatikan: paket ini tidak mengimpor paket postgres sama sekali.
type PenyimpanProduk interface {
	AmbilProduk(ctx context.Context, id int64) (Produk, error)
}

type Layanan struct {
	produk PenyimpanProduk
}

func NewLayanan(p PenyimpanProduk) *Layanan { return &Layanan{produk: p} }

// internal/produk/postgres.go — PENYEDIA tidak tahu interface itu ada.
type Postgres struct{ db *pgxpool.Pool }

func (p *Postgres) AmbilProduk(ctx context.Context, id int64) (Produk, error) { ... }

Kecil itu menang

type Reader interface { Read(p []byte) (int, error) }
type Writer interface { Write(p []byte) (int, error) }
type Closer interface { Close() error }

// Digabung lewat embedding
type ReadCloser interface {
	Reader
	Closer
}

io.Reader punya satu method, dan karena itu berkas, koneksi jaringan, body HTTP, buffer memori, arsip gzip, dan hasil enkripsi semuanya bisa dipakai di tempat yang sama. Semakin banyak method sebuah interface, semakin sedikit tipe yang bisa memenuhinya, dan semakin kecil manfaatnya.

Accept interfaces, return structs

// ✅ menerima abstrak, mengembalikan konkret
func NewLayanan(db PenyimpanProduk, log *slog.Logger) *Layanan

// ❌ mengembalikan interface menyembunyikan kemampuan dan menyulitkan pemakai
func NewLayanan(...) LayananInterface

Mengembalikan struct konkret membiarkan pemakai memutuskan sendiri abstraksi apa yang ia butuhkan. Mengembalikan interface memaksa semua pemakai memakai abstraksimu — termasuk yang butuh satu method tambahan yang kebetulan tidak masuk daftar.

Jebakan: interface nil yang tidak nil

type KesalahanSaya struct{}
func (*KesalahanSaya) Error() string { return "gagal" }

func bermasalah() error {
	var e *KesalahanSaya = nil   // pointer nil
	return e                      // dibungkus jadi interface error
}

if bermasalah() != nil {
	fmt.Println("MASUK SINI")    // ← ya, masuk. Meski nilainya nil.
}

Nilai interface terdiri dari dua hal: tipe dan nilai. Di atas, nilainya nil tapi tipenya *KesalahanSaya — jadi interface-nya tidak nil. Ini bug Go paling terkenal, dan bentuknya selalu sama: fungsi mengembalikan tipe error konkret alih-alih error.

Menguji tipe di balik interface

// type assertion — bentuk "comma ok" supaya tidak panik
if pg, ok := penyimpan.(*Postgres); ok {
	pg.Statistik()
}

// type switch
switch v := nilai.(type) {
case string:
	fmt.Println("teks", v)
case int, int64:
	fmt.Println("angka", v)
case error:
	fmt.Println("error", v)
default:
	fmt.Printf("tipe tak terduga %T\n", v)
}

Memastikan implementasi saat kompilasi

// Baris ini tidak menghasilkan apa pun saat runtime, tapi membuat compiler
// gagal kalau *Postgres berhenti memenuhi PenyimpanProduk.
var _ PenyimpanProduk = (*Postgres)(nil)

Tanpa baris ini, kesalahan baru muncul di tempat yang jauh — saat seseorang mencoba mengoper *Postgres ke konstruktor, dengan pesan error yang menyebut paket lain. Satu baris ini membuat kegagalan muncul tepat di berkas yang salah.