Comment fonctionne l'imbrication de struct (composition) ?

Question

Accepted Answer

Go n'a **pas d'héritage** — à la place, il utilise la **composition** via l'imbrication de struct. En imbriquant un struct (ou une interface) à l'intérieur d'un autre, le type externe gagne directement les champs et méthodes du type interne. C'est la réponse de Go à la réutilisation de code, favorisant la composition « has-a » plutôt que l'héritage « is-a ».

## Imbrication d'un struct

```go
type Animal struct {
    Name string
}
func (a Animal) Eat() string {
    return a.Name + " is eating"
}

type Dog struct {
    Animal    // EMBEDDED — no field name, just the type → composition
    Breed string
}

d := Dog{
    Animal: Animal{Name: "Rex"},
    Breed:  "Lab",
}

// Dog gets Animal's fields and methods PROMOTED — accessed directly
fmt.Println(d.Name)     // "Rex" — promoted from the embedded Animal
fmt.Println(d.Eat())    // "Rex is eating" — Animal's method, called on Dog
```

L'imbrication (écrire juste le nom du type, pas de nom de champ) **promeut** les champs et méthodes du type imbriqué vers le struct externe — donc `d.Name` et `d.Eat()` fonctionnent comme s'ils appartenaient à `Dog`. Cela ressemble à de l'héritage mais c'est de la composition : `Dog` *a un* `Animal`.

## Surcharge des méthodes promues

```go
func (d Dog) Eat() string {        // Dog defines its OWN Eat()
    return d.Name + " the dog eats noisily"
}
d.Eat()         // calls Dog's Eat (the outer one shadows the embedded one)
d.Animal.Eat()  // explicitly call the embedded Animal's Eat if needed
```

Le type externe peut définir une méthode avec le même nom pour « surcharger » (masquer) celle promue ; vous pouvez toujours accéder à la version imbriquée explicitement.

## Imbrication d'interfaces (très courant)

```go
// embed interfaces to compose larger ones
type Reader interface { Read(p []byte) (int, error) }
type Writer interface { Write(p []byte) (int, error) }

type ReadWriter interface {   // composed from both via embedding
    Reader
    Writer
}
// (this is exactly how io.ReadWriter is defined in the standard library)
```

L'imbrication d'interfaces compose de petites interfaces en des interfaces plus grandes — utilisée partout dans la bibliothèque standard.

## Composition plutôt qu'héritage — la philosophie Go

```text
No class hierarchies, no "extends". Instead:
  ✓ Embed to reuse fields/methods (has-a)
  ✓ Embed interfaces to compose behavior contracts
  ✓ Avoids the fragility, deep hierarchies, and tight coupling of inheritance
```

## Pourquoi c'est important

L'imbrication de struct est le **mécanisme distinctif de Go pour la réutilisation de code et la composition**, remplaçant l'héritage trouvé dans la plupart des langages POO. Comprendre cela est essentiel car c'est ainsi que Go réalise la réutilisation (promotion des champs/méthodes imbriqués pour que le type externe « hérite » du comportement par la composition) tout en évitant délibérément les problèmes bien connus de l'héritage (classes de base fragiles, hiérarchies profondes et rigides, couplage étroit).

Cela incarne le principe largement reconnu **« composition plutôt qu'héritage »**. L'imbrication apparaît constamment — imbrication de struct pour la réutilisation, imbrication d'interfaces pour construire des contrats plus grands (comme `io.ReadWriter`), et imbrication pour un comportement de type mixin.

Reconnaître que Go n'a pas d'héritage et que l'imbrication est son alternative compositionnelle — plus les règles de promotion et d'ombrage des méthodes — est fondamental pour lire et concevoir du Go idiomatique, et un sujet d'entretien courant étant donné la différence avec les langages basés sur les classes.