Reglas de satisfacción de interfaces

Parte de la sección Programación Orientada a Objetos del Journey de GO de Coddy — lección 43 de 107.

Aunque Go utiliza el tipado de pato (duck typing) para la satisfacción implícita de interfaces, existen reglas específicas que determinan si un tipo realmente satisface una interfaz. Comprender estas reglas te ayuda a evitar errores sutiles.

La regla más importante tiene que ver con los receptores de puntero. Si un método se define con un receptor de puntero, solo un puntero a ese tipo satisface la interfaz, no el valor en sí mismo:

type Saver interface {
    Save() string
}

type Document struct{ Name string }

func (d *Document) Save() string {  // receptor de puntero
    return "Saved: " + d.Name
}

func Process(s Saver) {
    fmt.Println(s.Save())
}

Debido a que Save() tiene un receptor de puntero, solo *Document satisface Saver:

func main() {
    doc := Document{Name: "report.txt"}
    
    Process(&doc)  // funciona - el puntero satisface la interfaz
    // Process(doc)  // error de compilación - el valor no satisface la interfaz
}

Sin embargo, lo inverso es más flexible. Si un método tiene un receptor de valor, tanto los tipos de valor como los de puntero satisfacen la interfaz. Go desreferencia automáticamente los punteros al llamar a métodos con receptor de valor:

func (d Document) Info() string {  // receptor de valor
    return d.Name
}

// Tanto Document como *Document satisfacen una interfaz que requiere Info()

Esta asimetría existe porque Go siempre puede obtener un valor de un puntero (mediante la desreferenciación), pero no siempre puede obtener un puntero de un valor (es posible que el valor no sea direccionable). Tener en cuenta esta regla evita errores de compilación confusos al trabajar con interfaces.

Desafío

Fácil

Vamos a construir un sistema de configuración que demuestre cómo los receptores de puntero y de valor afectan la satisfacción de las interfaces. Crearás tipos donde la elección del receptor determina si se pueden usar valores, punteros o ambos con una interfaz.

Organizarás tu código en tres archivos:

config.go: Define una interfaz Configurable que requiera dos métodos: GetValue() string y SetValue(string). Luego crea dos tipos de configuración:
- ReadOnlyConfig con un campo Value—usa un receptor de valor para GetValue() (devuelve el Value) y un receptor de puntero para SetValue() (actualiza el Value)
- Setting con un campo Data—usa receptores de valor para ambos métodos (GetValue devuelve Data, SetValue simplemente imprime "Cannot modify" sin cambiar nada)
processor.go: Crea una función llamada ProcessConfig que acepte un Configurable y una nueva cadena de valor. Debe imprimir el valor actual usando GetValue(), llamar a SetValue() con el nuevo valor, y luego imprimir el valor nuevamente para mostrar cualquier cambio.
main.go: Lee los detalles de configuración de la entrada y demuestra las reglas de satisfacción de interfaces:
1. Crea un ReadOnlyConfig y pasa un puntero a ProcessConfig (requerido porque SetValue tiene un receptor de puntero)
2. Crea un Setting y pasa el valor directamente a ProcessConfig (funciona porque ambos métodos tienen receptores de valor)

Se proporcionarán las siguientes entradas:

Línea 1: Valor inicial para ReadOnlyConfig
Línea 2: Nuevo valor a establecer para ReadOnlyConfig
Línea 3: Valor inicial para Setting
Línea 4: Nuevo valor a intentar para Setting

Tu función ProcessConfig debe imprimir en este formato:

Current: [value]
Current: [value after SetValue]

Por ejemplo, dados debug, production, localhost, y remote, tu salida debería ser:

Current: debug
Current: production
Current: localhost
Cannot modify
Current: localhost

Observa cómo ReadOnlyConfig realmente cambia su valor (porque pasamos un puntero), mientras que Setting permanece sin cambios (su SetValue con un receptor de valor no puede modificar el original). La idea clave es que los valores de ReadOnlyConfig por sí solos no satisfarían Configurable—solo los punteros lo hacen—mientras que los valores de Setting funcionan directamente porque todos sus métodos usan receptores de valor.

Hoja de referencia

Go utiliza el tipado de pato (duck typing) para la satisfacción implícita de interfaces, pero existen reglas específicas sobre los receptores de puntero y de valor:

Regla del Receptor de Puntero

Si un método tiene un receptor de puntero, solo un puntero a ese tipo satisface la interfaz:

type Saver interface {
    Save() string
}

type Document struct{ Name string }

func (d *Document) Save() string {  // pointer receiver
    return "Saved: " + d.Name
}

func main() {
    doc := Document{Name: "report.txt"}
    
    Process(&doc)  // works - pointer satisfies interface
    // Process(doc)  // compile error - value doesn't satisfy interface
}

Regla del Receptor de Valor

Si un método tiene un receptor de valor, tanto el tipo de valor como el de puntero satisfacen la interfaz:

func (d Document) Info() string {  // value receiver
    return d.Name
}

// Both Document and *Document satisfy an interface requiring Info()

Por qué existe esta asimetría

Go siempre puede obtener un valor a partir de un puntero (mediante la desreferenciación), pero no siempre puede obtener un puntero a partir de un valor (es posible que el valor no sea direccionable).

Pruébalo tú mismo

package main

import (
	"bufio"
	"fmt"
	"os"
)

func main() {
	scanner := bufio.NewScanner(os.Stdin)
	
	// Leer entradas
	scanner.Scan()
	rocInitial := scanner.Text()
	scanner.Scan()
	rocNew := scanner.Text()
	scanner.Scan()
	settingInitial := scanner.Text()
	scanner.Scan()
	settingNew := scanner.Text()
	
	// TODO: Crear un ReadOnlyConfig con el valor rocInitial
	// TODO: Pasar un PUNTERO a ProcessConfig (requerido porque SetValue tiene un receptor de puntero)
	
	// TODO: Crear un Setting con el valor settingInitial
	// TODO: Pasar el VALOR directamente a ProcessConfig (funciona porque ambos métodos tienen receptores de valor)
	
	// Usar estas variables para evitar errores de variables no utilizadas
	_ = rocInitial
	_ = rocNew
	_ = settingInitial
	_ = settingNew
}