Conflitti di nomi e accesso esplicito tramite x . Field

1. Come Go risolve i selettori x.Field e x.Method()

L'embedding spesso sembra una “magia di comodita”: si aggiunge Meta a una struttura e, all'improvviso, x.ID funziona anche se il campo ID non era stato dichiarato esplicitamente. Ma ogni magia ha un prezzo: nel momento in cui compaiono due sorgenti con lo stesso nome (due tipi embedded con un campo ID, oppure un tipo esterno e un tipo embedded con un metodo Validate), il compilatore smette di indovinare le vostre intenzioni. A quel punto entra in scena l'accesso esplicito: scrivere il percorso completo e non affidarsi alla telepatia del compilatore.

Quando scrivete x.Field o x.Method(), Go esegue una ricerca piuttosto rigorosa: non e “intuitiva”, e “meccanica”. Questa e una buona notizia: se capite la meccanica, il codice smette di essere un enigma. La cattiva notizia e che a volte la meccanica dice: “vedo due opzioni, decidi tu”, e ottenete un errore di compilazione invece di avviare il programma.

Immaginate che l'espressione x.Something sia una domanda al compilatore: “Trova Something nel valore x”. Il compilatore cerca i candidati per livelli: prima cio che e dichiarato direttamente nel tipo x, poi cio che e disponibile attraverso i campi embedded, poi attraverso embedded-embedded (annidati) e cosi via.

E utile tenere a mente una mini-tabella delle priorita:

Punto chiave: il “livello” e piu importante dell'“ordine di dichiarazione”. Non e C++ e non e “il primo che arriva vince”. Se allo stesso livello ci sono due nomi uguali, quello e un conflitto, non “chi ha fatto prima ha vinto”.

Come “debuggare” ambiguous selector nella propria testa

Quando il compilatore scrive ambiguous selector, e utile non andare nel panico, ma seguire un semplice diagramma mentale. Non richiede la conoscenza della specifica, solo buon senso.

flowchart TD
    A["Scriviamo x.Name / x.Method()"] --> B{"Esiste Name/Method direttamente nel tipo X?"}
    B -->|Yes| C["Si usa il membro diretto X.Name / X.Method"]
    B -->|No| D{"Esiste esattamente un candidato promoted tramite campi embedded?"}
    D -->|Yes| E["Si usa il membro promoted (abbreviazione)"]
    D -->|No, candidati 0| F["Errore: non esiste tale campo/metodo"]
    D -->|No, candidati 2+| G["Errore: ambiguous selector"]
    G --> H["Scriviamo esplicitamente: x.EmbeddedType.Name oppure x.EmbeddedType.Method()"]

Il punto e semplice: se esistono due opzioni equivalenti, Go non sceglie “a caso”. Siete voi a scegliere — in modo esplicito.

3. Conflitti di campi e accesso esplicito

Conflitto di campi: il classico ambiguous selector

I conflitti di campi sorgono piu spesso quando si incorporano due tipi che contengono entrambi nomi “comuni”: ID, Name, CreatedAt, Title. Nel codice di business questo e molto tipico: quasi ogni entita ha un ID, e quasi ogni entita ha qualcosa “legato al tempo”.

Vediamo un esempio minimo. Due tipi, entrambi contengono ID, ed entrambi sono incorporati in un terzo:

package main

type A struct{ ID int }
type B struct{ ID int }

type X struct {
	A
	B
}

func main() {
	_ = X{}
	// _ = X{}.ID // ambiguous selector X{}.ID
}

Se si decommenta la riga con X{}.ID, si ottiene un errore di compilazione del tipo ambiguous selector (la formulazione puo essere leggermente diversa, ma il senso e lo stesso). Il compilatore dice: “Vedo due ID: A.ID e B.ID. Non faro ipotesi”.

Questo e un punto importante: un tale errore non e un “problema di Go”, e una protezione contro i bug. Immaginate che il linguaggio scegliesse “il primo che capita” — avreste un comportamento dipendente dall'ordine dei campi. E l'ordine dei campi cambia per via dei refactoring, e quindi vi ritrovate con un “ieri funzionava, oggi si e rotto” senza alcuna modifica alla logica. Go non ama questo comportamento — e, onestamente, lo capisco.

Accesso esplicito: x.A.ID e perche serve

Quando sorge un conflitto, la soluzione e quasi sempre la stessa: smettere di scrivere l'abbreviazione e indicare il percorso. Cioe invece di x.ID scrivere x.A.ID oppure x.B.ID.

Amplifichiamo l'esempio e rendiamo esplicite le accessi:

package main

import "fmt"

type A struct{ ID int }
type B struct{ ID int }

type X struct{ A; B }

func main() {
	x := X{A: A{ID: 1}, B: B{ID: 2}}
	fmt.Println(x.A.ID, x.B.ID) // 1 2
}

Qui l'“accesso esplicito” non e una sintassi speciale. E semplicemente una normale catena di selettori: prima scegliamo il campo embedded A o B, poi scegliamo il campo ID all'interno.

E qui c'e un significato importante di design: l'embedding e solo un modo per accorciare la scrittura, ma la forma completa esiste sempre. Il tipo incorporato non scompare. Rimane un campo della struttura, solo senza un nome esplicitamente inventato da voi (il suo nome e il nome del tipo).

Esempio da applicazione: Task e metadati

Per non restare su un problema astratto con A e B, avviciniamoci alla nostra applicazione didattica. Supponiamo di costruire un piccolo modello di task: Task, con un titolo e uno stato di completamento. Vogliamo raggruppare con attenzione i campi: separatamente l'identificatore, separatamente l'audit (chi ha creato), separatamente i tempi.

Supponiamo di avere due “gruppi” di campi, e che entrambi contengano improvvisamente ID (si, succede anche questo — per esempio, Audit potrebbe conservare CreatedByID, ma un principiante a volte lo abbrevia in ID, e poi comincia il divertimento).

package main

type Ident struct{ ID int }
type Audit struct{ ID int } // bad name, but useful for the example

type Task struct {
	Title string
	Ident
	Audit
}

func main() {
	_ = Task{}
	// _ = Task{}.ID // ambiguous selector
}

Non appena vedete “due entita dentro una sola” con lo stesso nome di campo, potete quasi prevedere in anticipo che: t.ID diventera ambiguo.

La soluzione e la stessa: scrivere in modo esplicito:

package main

import "fmt"

type Ident struct{ ID int }
type Audit struct{ ID int }

type Task struct{ Title string; Ident; Audit }

func main() {
	t := Task{Title: "Read Go spec", Ident: Ident{ID: 10}, Audit: Audit{ID: 99}}
	fmt.Println(t.Ident.ID, t.Audit.ID) // 10 99
}

E qui sorge un pensiero naturale: “Ok, funziona, ma perche abbiamo mai permesso Audit.ID?”. Ottima domanda — ed e gia una questione di design, ma la conclusione pratica e questa: un conflitto di nomi a volte segnala che il modello puo essere reso piu chiaro.

4. Conflitti di metodi e composizione del comportamento

Conflitto di metodi: un x.Validate() ambiguo

A confliggere non possono essere solo i campi, ma anche i metodi. E a volte fa ancora piu male: i campi li vedete nella struttura, mentre i metodi possono essere “sollevati” dal tipo embedded, e nell'autocompletamento dell'IDE tutto sembra come se il metodo “appartenesse” al tipo esterno.

Modelizziamo la situazione. Ci sono due tipi, e entrambi hanno un metodo Validate() — per esempio, uno controlla il titolo, l'altro controlla i vincoli:

package main

type TitleRules struct{}
func (TitleRules) Validate() error { return nil }

type LimitRules struct{}
func (LimitRules) Validate() error { return nil }

type TaskRules struct {
	TitleRules
	LimitRules
}

func main() {
	r := TaskRules{}
	_ = r
	// _ = r.Validate() // ambiguous selector r.Validate
}

Qui si attiva di nuovo il principio: due candidati allo stesso livello significano ambiguita.

L'uscita e la stessa: percorso esplicito. E, cosa importante, funziona allo stesso modo per campi e metodi:

package main

type TitleRules struct{}
func (TitleRules) Validate() error { return nil }

type LimitRules struct{}
func (LimitRules) Validate() error { return nil }

type TaskRules struct{ TitleRules; LimitRules }

func main() {
	r := TaskRules{}
	_ = r.TitleRules.Validate()
	_ = r.LimitRules.Validate()
}

Se vi serve un “comportamento unificato” (per esempio eseguire entrambi i controlli), questo e un buon momento per definire un metodo del tipo esterno Validate (gia su TaskRules o su un altro tipo esterno), che chiami esplicitamente le parti necessarie. Questo non e piu un conflitto, ma una composizione consapevole.

Metodo controllato invece del conflitto

Supponiamo che nella nostra applicazione di task vogliamo che Task abbia una verifica di validita. Nel frattempo, le regole vivono in due tipi embedded. Invece di provare a chiamare t.Validate() (che entra in conflitto), possiamo creare il metodo Validate sul tipo esterno Task e all'interno chiamare esplicitamente i controlli necessari.

package main

type TitleRules struct{}
func (TitleRules) ValidateTitle(title string) error { return nil }

type LimitRules struct{}
func (LimitRules) ValidateLimits() error { return nil }

type Task struct {
	Title string
	TitleRules
	LimitRules
}

func (t Task) Validate() error {
	if err := t.TitleRules.ValidateTitle(t.Title); err != nil { return err }
	return t.LimitRules.ValidateLimits()
}

Notate come l'accesso esplicito (t.TitleRules..., t.LimitRules...) diventa uno strumento per controllare il comportamento. Ora Task ha un solo metodo chiaro Validate, e i dettagli interni non “escono” accidentalmente attraverso nomi promoted.

5. Sovrapposizione dei nomi e leggibilita

Sovrapposizione dei nomi: il tipo esterno “vince” sui membri promoted

C'e un altro caso interessante che confonde i principianti: il tipo esterno puo dichiarare un campo o un metodo con lo stesso nome di un membro promoted. In quel caso l'accesso breve portera al membro esterno, non a quello embedded.

Questo appare come una “sovrapposizione” (a volte si dice “shadowing”, ma attenzione: non e la stessa cosa dello shadowing delle variabili nei blocchi; il senso e simile, ma il contesto e diverso). Esempio:

package main

import "fmt"

type Meta struct{ Version int }

type Doc struct {
	Meta
	Version int
}

func main() {
	d := Doc{Meta: Meta{Version: 1}, Version: 2}
	fmt.Println(d.Version, d.Meta.Version) // 2 1
}

Qui d.Version e il campo Doc.Version, perche e dichiarato direttamente. E Meta.Version e ancora accessibile, solo che ora va indicato esplicitamente tramite d.Meta.Version.

Questo comportamento e importante da capire, perche influisce sulla “superficie del tipo”: l'embedding puo portare accidentalmente nomi che in seguito vorrete usare voi stessi. E allora, all'improvviso, parte del vecchio codice inizia a puntare altrove — oppure il compilatore inizia a lamentarsi se ora c'e un'ambiguita.

L'accesso esplicito come strumento di leggibilita

Quando le persone sentono per la prima volta “scrivete esplicitamente x.Inner.Field”, spesso lo interpretano come una punizione: “Go mi costringe a digitare roba inutile”. Ma nel codice reale l'accesso esplicito e spesso utile anche senza conflitti — semplicemente per rendere chiaro al lettore da dove proviene il campo.

Immaginate di leggere questo codice:

t.ID = 10
t.CreatedAt = now

Se ID e CreatedAt sono promoted da tipi embedded diversi, non lo vedete dalla riga di codice. Ora confrontate:

t.Ident.ID = 10
t.Audit.CreatedAt = now

Nella seconda variante si legge quasi come documentazione: dove sta l'identificatore, dove sta l'audit. S, avete digitato qualche simbolo in piu. Pero il prossimo sviluppatore (voi compresi tra una settimana) non dovra giocare al gioco “indovina chi ha portato questo campo”.

Molto spesso un buon compromesso e questo: nel codice semplice si puo usare l'accesso promoted, ma nei punti in cui contano gli invarianti, le responsabilita e il significato, scrivere in modo esplicito.

6. Errori tipici nei conflitti di nomi e nell'accesso esplicito

Errore n. 1: cercare di “battere il compilatore” invece di chiarire il percorso.
Quando un principiante vede ambiguous selector, la prima reazione e spesso strana: rinominare la variabile locale, spostare i campi, aggiungere un altro livello di wrapper — pur di “farlo funzionare”. Ma la causa quasi sempre e la coincidenza di nomi tra tipi embedded. La cura e semplice: indicate x.A.ID al posto di x.ID e vedete subito cosa volevate davvero.

Errore n. 2: usare l'accesso promoted ovunque e perdere l'origine dei dati.
Se nel modello ci sono molte parti incorporate, l'accesso breve rende il codice simile a un minestrone: vedete t.ID, t.Name, t.CreatedAt, ma non vedete quali parti sono responsabili dell'identita e quali dell'audit o dello stato. Anche se non c'e conflitto, l'abitudine di scrivere a volte t.Meta.CreatedAt oppure t.Ident.ID aumenta molto la leggibilita.

Errore n. 3: incorporare due tipi grandi e ottenere per sbaglio un conflitto di metodi in un punto inatteso.
I metodi sono meno visibili dei campi: potete incorporare due tipi che “da qualche parte” hanno lo stesso String() oppure Validate(), e il conflitto emergera solo quando provate a chiamare x.String() in un altro file. E fastidioso da diagnosticare se non si ricorda il promotion. In questi casi una chiamata esplicita tramite x.Inner.String() mostra rapidamente quali metodi stanno competendo.

Errore n. 4: “sovrapporre” un nome promoted e non accorgersi che il comportamento e cambiato.
Se nel tipo esterno compare un campo/metodo con il nome che prima arrivava dal tipo embedded, allora x.Name iniziera a significare qualcosa di diverso. A volte va bene, ma spesso e una fonte silenziosa di bug e incomprensioni. Aiuta l'abitudine: nei punti importanti accedere in modo esplicito al tipo incorporato (x.Meta.Name), cosi da non dipendere da cio che e stato “sollevato” accidentalmente all'esterno.

Errore n. 5: pensare che i conflitti siano “rari” e ignorarli nella progettazione del modello.
Nei piccoli esempi va tutto liscio. Ma appena il modello cresce, ID, Name, CreatedAt, UpdatedAt, Status compaiono ovunque. Il conflitto di nomi non e un'eccezione, ma il risultato naturale della crescita. Per questo l'embedding va fatto con consapevolezza: capire esattamente cosa state esponendo nell'API del tipo esterno, e essere pronti in qualunque momento a passare all'accesso esplicito quando la leggibilita conta piu della brevita.