pmomusic/.kilo/plans/1775382570642-kind-falcon.md

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:

     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如此一来 :

     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é.