---
title: "Types associés ou génériques dans une API de driver I/O"
description: "Utiliser les types associés dans les traits Rust pour concevoir des APIs flexibles et type-safe pour les drivers I/O bas niveau et comparer les avantages par rapport aux paramètres de type génériques"
url: "https://mayorana.ch/fr/blog/associated-types-io-driver-api"
language: "fr"
date: "2025-12-04"
author: "Mohamed Bennekrouf"
tags:
- "rust"
- "associated-types"
- "traits"
- "io-drivers"
- "type-safety"
- "embedded"
en_version: "https://mayorana.ch/en/blog/associated-types-io-driver-api.md"
---
# Types associés ou génériques dans une API de driver I/O
Dans un driver I/O bas niveau pour un système embarqué, j'utiliserais les types associés dans un trait Rust pour définir une API flexible et type-safe qui lie des types d'entrée/sortie spécifiques à chaque implémentation de driver. Contrairement aux paramètres de type génériques, les types associés fournissent une conception plus claire et plus contrainte, améliorant la clarté et maintenant les performances. Voici comment je procéderais avec un exemple.
## Concevoir le Trait avec des Types associés
Pour un driver I/O gérant les interfaces matérielles (ex : UART, SPI), je définirais un trait comme ceci :
```rust
trait IoDriver {
type Input; // Type de données à écrire
type Output; // Type de données à lire
fn write(&mut self, data: Self::Input) -> Result<(), ()>;
fn read(&mut self) -> Result;
}
```
### Types associés :
- **Input** : Le type que le driver accepte pour l'écriture (ex : `u8` pour les octets, `[u8]` pour les buffers).
- **Output** : Le type retourné lors de la lecture (ex : `u8`, `Option`).
**Pourquoi** : Chaque driver fixe ses types I/O, assurant la sécurité de type et un contrat clair sans flexibilité par appel.
## Implémentation : Driver UART
Pour un driver UART (série) qui envoie et reçoit des octets uniques :
```rust
struct UartDriver {
// État matériel (simplifié)
buffer: u8,
}
impl IoDriver for UartDriver {
type Input = u8; // Écrit des octets uniques
type Output = u8; // Lit des octets uniques
fn write(&mut self, data: u8) -> Result<(), ()> {
self.buffer = data;
Ok(()) // Simule une écriture matérielle
}
fn read(&mut self) -> Result {
Ok(self.buffer) // Simule une lecture matérielle
}
}
// Usage
let mut uart = UartDriver { buffer: 0 };
uart.write(42).unwrap();
assert_eq!(uart.read(), Ok(42));
```
## Comparaison avec les paramètres de Type génériques
Voici comment ça pourrait ressembler avec des generics à la place :
```rust
trait GenericIoDriver {
fn write(&mut self, data: T) -> Result<(), ()>;
fn read(&mut self) -> Result;
}
impl GenericIoDriver for UartDriver {
fn write(&mut self, data: T) -> Result<(), ()> {
// Problème : T pourrait être n'importe quoi—comment le gérer ?
// Peut-être restreindre avec un bound, mais toujours flou
unimplemented!()
}
fn read(&mut self) -> Result {
unimplemented!()
}
}
```
### Problèmes :
- **T est trop flexible**—`write` pourrait recevoir un `String` ou `i32`, mais UART attend `u8`. Les bounds comme `T: Into` ajoutent un overhead de conversion et de la complexité.
- **Monomorphization** génère du code pour chaque `T`, gonflant inutilement le binaire.
## Avantages des Types associés
### Sécurité de Type
**Types Associés** : `UartDriver` verrouille `Input` et `Output` à `u8`. Les appelants ne peuvent pas passer de types incompatibles :
```rust
uart.write("hello"); // Erreur de compilation : attendait u8, reçu &str
```
**Generics** : Nécessite des vérifications à l'exécution ou des bounds complexes, risquant des erreurs ou de l'overhead.
### Clarté de conception
**Types Associés** : Le trait déclare "ce driver fonctionne avec ces types spécifiques", rendant l'intention explicite. `UartDriver` est orienté octets, tandis qu'un `SpiDriver` pourrait utiliser `[u8]` :
```rust
struct SpiDriver;
impl IoDriver for SpiDriver {
type Input = [u8]; // Écritures de buffer
type Output = [u8]; // Lectures de buffer
fn write(&mut self, _data: [u8]) -> Result<(), ()> { Ok(()) }
fn read(&mut self) -> Result<[u8], ()> { Ok([0; 4]) }
}
```
**Generics** : L'intention est brouillée—`T` pourrait être n'importe quoi par appel, forçant les implémenteurs à gérer ou rejeter les types dynamiquement.
### Performance
**Types Associés** : [Dispatch statique](https://mayorana.ch/fr/blog/dispatch-performance-rust) avec une implémentation par driver. `write` et `read` s'inlinent directement vers les ops matérielles (ex : `mov` vers un registre), pas de conversion ou overhead de dispatch.
**Generics** : Fait la monomorphization pour chaque `T` utilisé, augmentant la taille du code (ex : `write`, `write`), même si le driver ne supporte qu'un type. Les bounds comme `T: Into` ajoutent des appels à l'exécution.
## Améliorer le système
### Usage générique
Enveloppe dans une fonction générique pour la commodité :
```rust
fn process_io(driver: &mut D, input: D::Input) -> D::Output {
driver.write(input).unwrap();
driver.read().unwrap()
}
let mut uart = UartDriver { buffer: 0 };
let result = process_io(&mut uart, 42); // Fonctionne avec u8
```
### Flexibilité
Ajoute des types associés pour les erreurs ou configs si nécessaire (ex : `type Error`).
## Exemple avancé : système Multi-Driver
```rust
// Type d'erreur personnalisé
#[derive(Debug, PartialEq)]
enum IoError {
BufferFull,
HardwareFailure,
InvalidData,
}
// Trait amélioré avec gestion d'erreur
trait AdvancedIoDriver {
type Input;
type Output;
type Error;
fn write(&mut self, data: Self::Input) -> Result<(), Self::Error>;
fn read(&mut self) -> Result;
fn flush(&mut self) -> Result<(), Self::Error>;
}
// Driver SPI avec gestion de buffer
struct SpiDriver {
buffer: Vec,
max_size: usize,
}
impl AdvancedIoDriver for SpiDriver {
type Input = Vec;
type Output = Vec;
type Error = IoError;
fn write(&mut self, data: Vec) -> Result<(), IoError> {
if data.len() > self.max_size {
return Err(IoError::BufferFull);
}
self.buffer = data;
Ok(())
}
fn read(&mut self) -> Result, IoError> {
Ok(self.buffer.clone())
}
fn flush(&mut self) -> Result<(), IoError> {
self.buffer.clear();
Ok(())
}
}
// Fonction générique pour traiter n'importe quel driver
fn handle_io(
driver: &mut D,
data: D::Input
) -> Result {
driver.write(data)?;
let result = driver.read()?;
driver.flush()?;
Ok(result)
}
```
## Vérifier que ça compile comme prévu
### Vérification de compilation
S'assurer que les incompatibilités de types échouent :
```rust
uart.write([1, 2, 3]); // Erreur : attendait u8, reçu [i32; 3]
```
### Benchmark
Utilise criterion pour confirmer l'absence d'overhead :
```rust
use criterion::{black_box, Criterion};
fn bench(c: &mut Criterion) {
let mut uart = UartDriver { buffer: 0 };
c.bench_function("uart_write", |b| b.iter(|| uart.write(black_box(42))));
}
```
Attends-toi à des cycles minimaux, équivalents à l'accès matériel brut.
## Quand chacune est le bon choix
### Utilise les Types associés quand :
- Chaque implémentation a des types I/O fixes
- Tu veux une API claire et contrainte
- La performance est critique (pas de monomorphization inutile)
- Tu conçois des drivers matériels spécialisés
### Utilise les Generics quand :
- Tu as besoin de flexibilité par appel
- Les types varient dynamiquement
- Tu implémentes des algorithmes génériques
- L'uniformité n'est pas requise par implémentation
J'utiliserais les types associés dans `IoDriver` pour fixer `Input` et `Output` par driver, comme avec `UartDriver`, assurant la sécurité de type et une API claire plutôt que la sur-flexibilité des generics. Cela évite le gonflage de monomorphization et les conversions à l'exécution, délivrant du code efficace et inliné pour un système I/O embarqué. Cette conception équilibre utilisabilité et performance, exploitant le système de types de Rust pour des drivers robustes.