3.5Composants, modèles & réutilisation
L'essentiel en 30 secondes
- Modèles et fenêtres internes suppriment la duplication d'écrans : une modification du modèle se répercute sur toutes les fenêtres qui en héritent.
- Le composant empaquette un ensemble cohérent (fenêtres, procédures, classes, états) pour le réutiliser dans d'autres projets, avec correction centralisée.
- Versionner, documenter et garder une interface stable : un composant qui change sans cesse fragilise tous les projets utilisateurs.
Mini-cas filé — Yacine mutualise les écrans de sa gestion
Yacine doit livrer une seconde application au groupe : la gestion des utilisateurs et des droits. Il commence par ses écrans de négoce : cinq fiches partagent le même bandeau, le même logo et les mêmes boutons. Il crée un modèle de fenêtre FEN_FicheModele et fait hériter les cinq fiches : une modification du bandeau se répercute partout. Le bloc de saisie d'adresse, répété dans la commande et la facture, devient une fenêtre interne FI_AdresseLivraison. Pour la gestion des utilisateurs, il empaquette un composant COMP_Utilisateurs avec une interface stable, documentée et versionnée. Il note le réflexe : modèle pour l'apparence, fenêtre interne pour un bloc, composant pour un module partagé.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 3.5.
1. Modèles, fenêtres internes, superchamps
La réutilisation est la marque du développeur expérimenté : ne pas réécrire ce qui existe. Le modèle de fenêtre (ou d'état) définit une présentation commune — bandeau, logo, boutons standards. Les fenêtres qui en héritent reprennent ces éléments, et une modification du modèle se répercute sur toutes. La fenêtre interne est un bloc réutilisable inséré dans d'autres fenêtres : un sélecteur de client ou une saisie d'adresse écrit une fois, utilisé partout. Le superchamp regroupe des champs avec leur comportement et se dépose comme un champ unique.
2. Le composant, mécanisme le plus puissant
Le composant empaquette un ensemble d'éléments — fenêtres, procédures, classes, états — pour le réutiliser dans d'autres projets. Yacine développe une fois un module de gestion des utilisateurs ou de connexion à un service, puis l'intègre dans plusieurs applications. Le composant expose une interface visible de l'extérieur et cache son fonctionnement interne. Les bénéfices sont la capitalisation du savoir-faire, la correction centralisée et l'homogénéité entre applications.
3. Versions et interface stable
Un composant partagé demande de la discipline : gérer les versions pour savoir quel projet utilise quelle version, documenter son usage et concevoir une interface stable. Si l'interface change constamment, tous les projets utilisateurs doivent être repris. Avant de développer une brique, Yacine vérifie aussi si elle existe déjà dans la bibliothèque PC SOFT ou la communauté. Le bon réflexe : réutiliser, mais sans casser les projets qui dépendent du module.
🔎 Exemple concret — 🔎 Exemple concret — Du modèle au composant
Yacine réutilise à trois niveaux dans sa gestion de matériel électrique :
// Modele FEN_FicheModele : bandeau, logo, boutons Valider/Annuler
// Les fenetres FEN_Produit, FEN_Client, FEN_Fournisseur en heritent.
// Fenetre interne FI_AdresseLivraison inseree dans FEN_Commande
// et FEN_Facture : un seul comportement, aucun copier-coller.
// Composant COMP_Utilisateurs, partage avec une autre application
COMP_Utilisateurs.OuvreFiche(UtilisateurConnecte)
SI COMP_Utilisateurs.EstAutorise("FACTURATION") ALORS
Ouvre(FEN_Facture)
FINLecture : le modèle gère l'apparence, la fenêtre interne le bloc, le composant le module complet.
Leçon : l'interface du composant reste stable pour ne pas casser les projets utilisateurs.
Vocabulaire de la section
- Modèle de fenêtre
- Fenêtre-type définissant une présentation commune dont héritent les fenêtres de l'application.
Exemple simple : FEN_FicheModele porte le bandeau et les boutons des cinq fiches de Yacine.
Ce que ce n'est pas : une fenêtre recréée à la main pour chaque écran.
Réflexe : apparence commune → un modèle.
- Fenêtre interne
- Fenêtre réutilisable insérée dans d'autres fenêtres, avec son comportement.
Exemple simple : FI_AdresseLivraison est insérée dans la commande et la facture.
Ce que ce n'est pas : un bloc recopié dans chaque écran avec ses traitements.
Réflexe : bloc répété → fenêtre interne.
- Superchamp
- Ensemble de champs regroupés et réutilisables avec leur comportement, déposable comme un champ.
Exemple simple : Yacine regroupe les champs de recherche client dans un superchamp.
Ce que ce n'est pas : des champs séparés redéposés à chaque écran.
Réflexe : champs groupés réutilisables → superchamp.
- Composant
- Ensemble d'éléments empaqueté pour être réutilisé dans d'autres projets, avec une interface.
Exemple simple : COMP_Utilisateurs gère les droits dans plusieurs applications du groupe.
Ce que ce n'est pas : une collection de procédures limitée à un seul projet.
Réflexe : partager entre projets → un composant.
- Interface stable
- Partie visible d'un composant, qui doit rester prévisible pour les projets utilisateurs.
Exemple simple : Yacine documente et versionne les méthodes publiques de COMP_Utilisateurs.
Ce que ce n'est pas : une interface modifiée à chaque livraison sans préavis.
Réflexe : protéger les projets utilisateurs → interface stable.
En pratique — En pratique — Réutiliser plutôt que dupliquer
- Créez un modèle de fenêtre avec la présentation commune et faites-en hériter vos écrans, comme Yacine.
- Transformez un bloc répété (saisie d'adresse, recherche client) en fenêtre interne réutilisable.
- Pour un module destiné à plusieurs projets, créez un composant avec une interface claire et documentée.
- Versionnez et documentez le composant ; vérifiez si la brique existe déjà dans la bibliothèque PC SOFT.
Script pas-à-pas — mutualiser comme Yacine (4 min)
1) Repérez la présentation commune de plusieurs écrans et créez un modèle de fenêtre. 2) Faites hériter les écrans existants et vérifiez que la modification se répercute. 3) Isolez un bloc répété en fenêtre interne avec son comportement. 4) Pour un module partagé entre projets, définissez une interface stable et documentée. 5) Versionnez le composant et notez quel projet utilise quelle version.
Gardez ce réflexe : réutiliser sans casser — une interface de composant se change avec précaution.
Modèle copier-coller — la fiche réutilisation de Yacine
Modele : presentation commune heritee (bandeau, boutons)
Fenetre interne: bloc reutilisable insere (adresse, recherche)
Superchamp : champs groupes + comportement
Composant : module empaquete pour D'AUTRES projets
Vigilance : interface stable, documentation, versionsCinq fiches identiques
Yacine crée un modèle et fait hériter les fiches : le bandeau se modifie une seule fois.
Une adresse répétée
Yacine isole la saisie d'adresse en fenêtre interne utilisée dans la commande et la facture.
Un module multi-projets
Yacine empaquette la gestion des utilisateurs en composant versionné.
Une interface qui change
Yacine documente et stabilise l'interface du composant pour ne pas casser les autres applications.
✓ Bonnes pratiques
- Modèle pour l'apparence, fenêtre interne pour un bloc.
- Composant pour un module partagé entre plusieurs projets.
- Toujours versionner et documenter.
✗ Pièges fréquents
- Recréer le même bandeau dans chaque fenêtre.
- Copier un bloc au lieu d'une fenêtre interne.
- Changer l'interface d'un composant sans précaution.
Points clés à retenir
- Les modèles diffusent une présentation commune héritée.
- Les fenêtres internes et superchamps réutilisent des blocs avec leur comportement.
- Le composant empaquette un module pour d'autres projets.
- Versionner, documenter et garder une interface stable.
Défi 48h — appliquez demain
Comme Yacine, repérez la présentation commune de plusieurs fenêtres et créez un modèle dont elles héritent. Transformez un bloc répété (adresse, recherche client) en fenêtre interne. Enfin, identifiez un module destiné à plusieurs projets et décrivez en une phrase son interface stable, sa documentation et sa politique de version.
- Je sais quand utiliser modèle, fenêtre interne ou superchamp.
- Je distingue un composant d'une collection de procédures.
- Je comprends l'importance des versions et d'une interface stable.
Questions fréquentes
Quand créer un composant plutôt qu'une simple collection de procédures ?
Créez un composant quand le module doit être partagé entre plusieurs projets et qu'il forme un ensemble cohérent avec des fenêtres, des états ou des classes. Une collection de procédures suffit pour organiser le code à l'intérieur d'un même projet. Le composant apporte la correction centralisée et l'encapsulation, mais impose de concevoir une interface, de documenter, de versionner et de tester.
Comment garantir la cohérence visuelle sans tout refaire à la main ?
En combinant trois niveaux : la charte graphique pour les styles globaux, les modèles de fenêtres pour la structure commune — bandeau, logo, boutons standards — et les fenêtres internes pour les blocs répétés. Une modification du modèle se répercute sur toutes les fenêtres qui en héritent. La règle est de centraliser l'apparence plutôt que de styliser chaque champ individuellement.
Quand un composant est-il plus pertinent qu'une collection de procédures ?