Eric Coissac
512dcd1803
- Remplacer les macro_rules! `add_arg_in` et `add_out`, ainsi que la duplication manuelle d’ajout de variables/actions, par des fonctions explicites (`add_arg_in`, `all arg_out`, etc.) - Introduire des fonctions utilitaires génériques pour `add_var`, `add_action` afin d’unifier la gestion des erreurs - Mettre à jour tous les services UPnP (`build_avtransport`, `renderingcontrol_service_builder` et autres) pour utiliser les nouvelles fonctions - Supprimer le code redondant dans la construction des actions (ex: ~12 lignes dupliquées) - Ajouter le fichier de plan `.kilo/plans/17xx-kind-falcon.md` décrivant la refonte - Vérifier que les imports et signatures sont cohérents (ex: `&Arc<StateVariable>`)
58 lines
2.9 KiB
Markdown
58 lines
2.9 KiB
Markdown
# Refonte de `pmowebrenderer` – Élimination des redondances
|
||
|
||
## Objectif
|
||
Réduire la duplication de code entre les fonctions de construction de services UPnP (`build_avtransport`, `build_renderingcontrol`, `build_connectionmanager`) et les macros d’ajout d’arguments (`add_arg_in!`, `add_arg_out!`).
|
||
Cela améliore la maintenabilité, la lisibilité et diminue le risque d’incohérences.
|
||
|
||
## Étapes détaillées
|
||
|
||
1. **Création d’une fonction générique `build_service`**
|
||
- Signature proposée:
|
||
```rust
|
||
fn build_service(
|
||
name: &str,
|
||
variables: Vec<Arc<Variable>>,
|
||
actions: Vec<Action>,
|
||
handlers: Vec<Handler>,
|
||
) -> Result<Service, FactoryError>
|
||
```
|
||
- Implémentation unique de l’ajout de variables, d’actions et de handlers.
|
||
- Chaque fonction existante (`build_avtransport`, `build_renderingcontrol`, `build_connectionmanager`) appelle `build_service` avec les paramètres spécifiques.
|
||
|
||
2. **Refactorisation des macros**
|
||
- Remplacer `macro_rules! add_arg_in!` et `add_arg_out!` par des fonctions如此一来 :
|
||
```rust
|
||
fn add_arg_in(action: &mut Action, name: &str, var: Arc<Argument>) -> Result<(), FactoryError>
|
||
fn add_arg_out(action: &mut Action, name: &str, var: Arc<Argument>) -> Result<(), FactoryError>
|
||
```
|
||
- Ces fonctions encapsulent la logique d’ajout d’arguments et centralisent la gestion d’erreur.
|
||
|
||
3. **Mise à jour des implémentations**
|
||
- Modifier `build_avtransport`, `build_renderingcontrol`, `build_connectionmanager` pour déléguer à `build_service` et aux nouvelles fonctions d’argument.
|
||
- Vérifier que les imports restent cohérents (ajouter `use` nécessaires pour `Variable`, `Handler`, etc.).
|
||
|
||
4. **Suppression des ancrés macros**
|
||
- Retirer les declarations `macro_rules! add_arg_in!` et `macro_rules! add_arg_out!` du fichier `renderer.rs`.
|
||
- Adapter le code appelant pour utiliser les fonctions concrètes.
|
||
|
||
5. **Tests et CI**
|
||
- Ajouter des tests unitaires couvrant les nouvelles fonctions `build_service`, `add_arg_in`, `add_arg_out`.
|
||
- Configurer le pipeline CI pour exécuter `cargo test` et `cargo clippy` afin de détecter d’éventuelles regressions.
|
||
|
||
6. **Documentation**
|
||
- Mettre à jour les commentaires pour refléter les nouvelles abstractions.
|
||
- Ajouter une section « Refactorisation » dans le `README` décrivant les changements.
|
||
|
||
## Impact attendu
|
||
- **Réduction** : ~12 lignes de code redondantes éliminées.
|
||
- **Maintenabilité** : modification centralisée de la logique de construction de services.
|
||
- **Robustesse** : baisse du risque d’incohérences et de bugs liés à la duplication.
|
||
- **Lisibilité** : code plus explicite et plus proche du modèle de domaine.
|
||
|
||
## Prochaines actions
|
||
1. Implémenter les changements proposés dans les fichiers concernés.
|
||
2. Exécuter la suite de tests pour valider la refonte.
|
||
3. Commiter les modifications après revue.
|
||
|
||
---
|
||
Plan finalisé. |