---
title: "Rendre les Traits Object-Safe pour dyn Trait de Rust dans les Systèmes de Plugins"
description: "Comprendre l'object safety en Rust et refactoriser les traits pour le dispatch dynamique"
url: "https://mayorana.ch/fr/blog/object-safety-rust"
language: "fr"
date: "2025-12-01"
author: "Mohamed Bennekrouf"
tags:
- "rust"
- "object-safety"
- "dynamic-dispatch"
- "traits"
- "plugins"
en_version: "https://mayorana.ch/en/blog/object-safety-rust.md"
---
# Rendre les Traits Object-Safe pour dyn Trait de Rust dans les Systèmes de Plugins
Rust exige que les traits soient **object-safe** pour les utiliser avec `dyn Trait` pour le [dispatch dynamique](https://mayorana.ch/fr/blog/dispatch-performance-rust), car cela assure une vtable (table virtuelle) cohérente pour les appels de méthodes à l'exécution. Les traits non-object-safe, comme ceux avec des méthodes génériques ou des exigences statiques, ne peuvent pas être utilisés avec `dyn Trait`, mais ils peuvent être refactorisés pour les systèmes de plugins nécessitant du polymorphisme à l'exécution. Je vais expliquer pourquoi l'object safety est nécessaire et démontrer comment refactoriser un trait non-object-safe pour un système de plugins.
## Pourquoi l'Object Safety Compte
Un trait est **object-safe** si :
- Toutes les méthodes ont un receiver (`&self`, `&mut self`) ou pas de receiver, mais pas static.
- Les méthodes n'utilisent pas `Self` comme type de retour ou paramètre générique (sauf dans les clauses `where`).
- Les méthodes ne sont pas génériques (pas de paramètres ``).
`dyn Trait` utilise un **fat pointer** (pointeur données + pointeur vtable) pour appeler les méthodes à l'exécution. Les traits non-object-safe empêchent la construction de vtable parce que :
- **Méthodes Génériques** : Différents paramètres de type créent des signatures de méthodes variées, rendant impossible une vtable unique.
- **Retours Self** : La taille et le type de `Self` diffèrent par implémenteur, cassant l'uniformité de la vtable.
- **Méthodes Statiques** : Celles-ci manquent d'une instance sur laquelle dispatcher, donc elles ne rentrent pas dans une vtable.
## Exemple : Trait Non-Object-Safe
Considère un système de plugins pour des transformateurs de données :
```rust
trait Transformer {
fn transform>(&self, value: T) -> f64; // Méthode générique
fn new() -> Self; // Statique, retourne Self
}
struct SquareTransformer;
impl Transformer for SquareTransformer {
fn transform>(&self, value: T) -> f64 {
let v = value.into();
v * v
}
fn new() -> Self { SquareTransformer }
}
// Échoue : Le trait n'est pas object-safe
// let transformer: Box = Box::new(SquareTransformer);
```
**Problèmes** :
- `transform` : Générique, nécessitant une entrée vtable unique par `T`.
- `new()` : Statique avec retour `Self`, variant par implémenteur et manquant de receiver.
## Refactorisé : Version Object-Safe
Pour activer `dyn Trait` pour un système de plugins :
```rust
trait Transformer {
fn transform(&self, value: f64) -> f64; // Pas de generics, type fixe
}
struct SquareTransformer;
impl Transformer for SquareTransformer {
fn transform(&self, value: f64) -> f64 {
value * value
}
}
// Fonction factory pour l'instanciation
fn create_square_transformer() -> Box {
Box::new(SquareTransformer)
}
// Usage dans le système de plugins
fn main() {
let transformer: Box = create_square_transformer();
let result = transformer.transform(3.0); // 9.0
}
```
### Changements Apportés
- **Supprimé les Generics** : Changé `transform>` en `transform(&self, value: f64)`. La vtable a maintenant une seule entrée fixe : `fn(&self, f64) -> f64`.
- **Compromis** : Moins flexible (seulement `f64`, pas `i32` ou `f32`), mais les plugins peuvent convertir les entrées en externe.
- **Supprimé la Méthode Statique** : Retiré `new() -> Self`. Les méthodes statiques n'appartiennent pas aux vtables.
- **Solution** : Ajouté une fonction factory (`create_square_transformer`) pour l'instanciation. Un chargeur de plugins pourrait utiliser un registre :
```rust
use std::collections::HashMap;
let mut plugins: HashMap Box> = HashMap::new();
plugins.insert("square".to_string(), create_square_transformer);
```
## Comment ça Active dyn Trait
- **Construction de Vtable** : Le `Transformer` refactorisé a une méthode avec une signature fixe, activant une vtable comme :
```rust
// Vtable conceptuelle
struct TransformerVtable {
transform: fn(*const (), f64) -> f64, // Pointeur vers SquareTransformer::transform
}
```
Un `Box` associe cette vtable avec l'instance pour les appels à l'exécution.
- **Sécurité** : Pas de generics ou `Self` assure que la vtable est type-agnostic, sûre pour tout implémenteur.
- **Efficacité** : Le dispatch dynamique ajoute un lookup vtable (1-2 cycles), mais active le polymorphisme à l'exécution essentiel pour les plugins chargés dynamiquement.
## Là où ça se complique
### Gestion de Multiples Types d'Entrée
Si tu as besoin de flexibilité de type, utilise des enums ou des traits helper :
```rust
#[derive(Debug)]
enum Value {
Int(i32),
Float(f64),
Text(String),
}
impl Value {
fn to_f64(&self) -> f64 {
match self {
Value::Int(i) => *i as f64,
Value::Float(f) => *f,
Value::Text(s) => s.parse().unwrap_or(0.0),
}
}
}
trait Transformer {
fn transform(&self, value: &Value) -> f64;
}
impl Transformer for SquareTransformer {
fn transform(&self, value: &Value) -> f64 {
let v = value.to_f64();
v * v
}
}
```
### Système de Plugin complet
```rust,ignore
use std::collections::HashMap;
type PluginFactory = fn() -> Box;
struct PluginRegistry {
factories: HashMap,
}
impl PluginRegistry {
fn new() -> Self {
Self { factories: HashMap::new() }
}
fn register(&mut self, name: &str, factory: PluginFactory) {
self.factories.insert(name.to_string(), factory);
}
fn create(&self, name: &str) -> Option> {
self.factories.get(name).map(|f| f())
}
}
fn main() {
let mut registry = PluginRegistry::new();
registry.register("square", create_square_transformer);
if let Some(transformer) = registry.create("square") {
let result = transformer.transform(4.0); // 16.0
println!("Résultat : {}", result);
}
}
```
## Ce qui rend un trait object-safe
**Object Safety** : Élimine les generics, `Self` returns et méthodes statiques pour activer `dyn Trait`
**Factory Pattern** : Utilise des fonctions factory au lieu de méthodes `new()` statiques
**Compromis** : Moins de flexibilité de type contre la capacité de dispatch dynamique
Essentiels pour les systèmes de plugins où les types sont inconnus pendant la compilation
**Astuce** : Utilise `cargo check` pour vérifier rapidement si tes traits sont object-safe avant d'essayer `dyn Trait` !