El conjunto de métodos (method set) de un tipo de datos define de manera estricta los métodos que pueden ser invocados sobre un operando de dicho tipo o que el tipo “posee” para satisfacer una interfaz específica. Esta propiedad es una característica intrínseca del sistema de tipos de Go y se utiliza para determinar la compatibilidad en tiempo de compilación entre tipos concretos e interfaces.
Este comportamiento existe en Go para garantizar la seguridad de memoria y la claridad en la propiedad de los datos, resolviendo el problema de la ambigüedad en la mutabilidad presente en lenguajes con herencia tradicional o despacho dinámico opaco. Al separar los métodos por tipo de receptor (valor o puntero), Go evita que se realicen modificaciones accidentales sobre copias de valores y asegura que solo los operandos direccionables puedan ejecutar lógica que altere el estado interno del objeto, manteniendo una distinción clara entre semántica de valor y semántica de puntero.
Reglas de pertenencia y asignabilidad
El mecanismo interno se rige por dos reglas fundamentales de visibilidad. Para cualquier tipo T, su conjunto de métodos consiste únicamente en aquellos declarados con un receptor de valor (t T). En contraste, el conjunto de métodos del tipo puntero *T es más amplio: incluye tanto los métodos con receptor de valor (t T) como los de receptor de puntero (t *T). Esta asimetría es crucial cuando se evalúa la satisfacción de interfaces.
Cuando se intenta realizar una asignación de un tipo a una interfaz (assignability), el compilador verifica si el conjunto de métodos del tipo es un superconjunto de los métodos definidos por la interfaz. Si una interfaz requiere un método que fue declarado con un receptor de puntero, un valor de tipo T no podrá satisfacer la interfaz, ya que dicho método no forma parte de su conjunto de métodos. Sin embargo, un puntero *T sí la satisfará, pues hereda los métodos de valor por desreferenciación automática.
package main
import "fmt"
type Validador interface {
Validar() bool
Resetear()
}
type Documento struct {
Estado bool
}
// Método con receptor de valor: pertenece al conjunto de Documento y *Documento
func (d Documento) Validar() bool {
return d.Estado
}
// Método con receptor de puntero: pertenece SOLO al conjunto de *Documento
func (d *Documento) Resetear() {
d.Estado = false
}
func main() {
doc := Documento{Estado: true}
// Error de compilación: Documento does not implement Validador
// (Resetear method has pointer receiver)
// var i Validador = doc
var i Validador = &doc // Correcto: *Documento posee ambos métodos
fmt.Printf("Interfaz satisfecha: %v\n", i.Validar())
}
La restricción técnica más relevante es que Go no puede generar automáticamente un puntero a partir de un valor si este no es direccionable, lo que impide que el conjunto de métodos de T incluya métodos de *T.
La ilusión de la direccionabilidad en literales y mapas
Un comportamiento no obvio del compilador es la capacidad de invocar métodos de puntero directamente sobre variables de valor mediante “azúcar sintáctico”. Si se tiene una variable v de tipo T, Go permite escribir v.MetodoPuntero() transformándolo internamente en (&v).MetodoPuntero(). No obstante, esta conveniencia desaparece en el contexto de las interfaces o cuando el valor no reside en una variable direccionable.
Un edge case común ocurre con los elementos de un mapa. En Go, los valores almacenados en un mapa no son direccionables debido a que la implementación interna del mapa puede mover los datos en memoria durante una operación de crecimiento (evacuación de buckets). Intentar obtener la dirección de un elemento de un mapa para satisfacer una interfaz con métodos de puntero resultará en un error de compilación inmediato.
func ejemploMapa() {
m := map[string]Documento{"test": {Estado: true}}
// m["test"].Resetear()
// Error: cannot call pointer method on m["test"] (non-addressable)
ptrM := map[string]*Documento{"test": {Estado: true}}
ptrM["test"].Resetear() // Válido: el valor ya es un puntero
}
Esta limitación subraya la importancia de elegir el tipo de receptor basado no solo en la necesidad de mutar el estado, sino en cómo se planea consumir el tipo a través de interfaces o estructuras de datos de la biblioteca estándar.
- Módulo: Métodos e Interfaces
- Artículo número: #81