Quelle est la différence entre les relations is-a et has-a ?

Question

Accepted Answer

**Is-a** est une relation de *type* — modélisée avec l'**héritage** (une `Car` *est une* `Vehicle`). **Has-a** est une relation de *composition* — modélisée avec la **composition** (une `Car` *a un* `Engine`). Choisir le bon type est une décision de modélisation fondamentale.

## Les deux relations

```java
// IS-A → inheritance
class Vehicle { void move() {} }
class Car extends Vehicle { }        // a Car IS A Vehicle

// HAS-A → composition
class Engine { void start() {} }
class Car2 {
    private Engine engine = new Engine();   // a Car HAS AN Engine
    void start() { engine.start(); }        // delegate to the part
}
```

## Le test classique

Demandez-vous : « Est-ce que X *est une sorte de* Y, ou est-ce que X *a/utilise* un Y ? »

```text
A Dog        IS-A Animal        → inheritance ✅
A Car        HAS-A Engine       → composition ✅
A Square     IS-A Shape         → inheritance ✅
A Manager    HAS Employees      → composition (a list) ✅
A Stack      HAS-A list (not IS-A) → composition (see earlier pitfall) ✅
```

## Piège

Les gens ont recours à l'héritage pour *réutiliser du code*, même quand la relation est vraiment has-a. Si vous ne pouviez jamais substituer la sous-classe à la classe de base partout, ce n'est probablement pas is-a — utilisez plutôt la composition.

## Pourquoi c'est important

Cette distinction est la règle de décision pratique derrière « favoriser la composition plutôt que l'héritage » : choisissez la relation qui est vraie, pas celle qui économise quelques lignes.

Bien la choisir maintient les hiérarchies peu profondes et sincères, et cela prévient les violations de Liskov où un « sous-type » ne peut pas réellement se substituer à son parent.