# 16. Dispatch, override et modificateurs

## 16.1 Ordre canonique — V1 REQUIS — FIGÉ

Ordre des modificateurs :

```text
visibility
-> safety
-> linkage / ABI
-> type / dispatch modifiers
-> override
-> declaration kind
```

Puis :

```text
Name<...>
-> extends ...
-> implements ...
```

`extends` et `implements` sont des clauses après le nom, pas des modificateurs.

Exemples :

```text
public final class User
public open class Service
public abstract class Base
public unsafe extern "C" union NativeValue
protected open method calculate(...)
protected override method calculate(...)
protected final override method calculate(...)
```

Les ordres alternatifs sont des erreurs syntaxiques même s'ils seraient théoriquement compréhensibles.

## 16.2 Méthodes overridables — V1 REQUIS — FIGÉ

Une méthode nouvellement déclarée n'est pas overridable par défaut.

Elle doit être explicitement :

```text
open method
```

ou :

```text
abstract method
```

Un descendant utilise :

```text
override method
```

Pour fermer ensuite la chaîne :

```text
final override method
```

`final method` sur une nouvelle méthode n'apporte rien et n'est pas nécessaire : l'absence de `open` suffit.

Même modèle pour `clsmethod` si elle participe au dispatch de classe.

## 16.3 Visibilité d'override — V1 REQUIS — FIGÉ

Un override conserve exactement la visibilité du contrat hérité.

Pas d'élargissement ni de réduction implicite.

Une exposition plus large nécessite un wrapper explicite.

## 16.4 `protected` — V1 REQUIS — FIGÉ EN PRINCIPE

`protected` existe uniquement dans le modèle d'héritage de classe et signifie « accessible depuis les classes dérivées » en plus de la classe déclaratrice.

Les détails d'accès via une autre instance d'une classe dérivée doivent être figés dans les règles finales de résolution membre.

---