En 2 heures, clarifie comment structurer une hiérarchie Véhicule → Voiture / Camion / Moto propre et évolutive, sans te perdre dans une usine à gaz d’héritage.
Exemples en WINDEV / WLangage, concepts applicables dans tous les langages objets.
Grid section
Tu sais créer une classe qui hérite de une autre, mais tu doutes : “Est-ce que je devrais vraiment dériver ici ?”
Tu as peur de casser un morceau de l’appli dès que tu touches à la classe de base.
Tu rajoutes des SI partout au lieu d’utiliser correctement le modèle objet.
Des classes tellement génériques que plus personne n’ose y toucher.
Des dérivées qui n’ont plus vraiment de lien logique avec la classe de base.
Des refactorings douloureux qui te donnent envie de tout réécrire en procédural.
La vérité, c’est que l’héritage est un outil puissant… quand il est bien utilisé. Mal utilisé, il rend ton code fragile, incompréhensible, et impossible à faire évoluer.
Distinguer ce qui doit vivre dans la classe Véhicule de ce qui est propre à Voiture / Camion / Moto.
Identifier les bons critères de séparation (règles métiers, usage réel, pas juste “technique”).
Éviter les classes “fourre-tout” qui cassent ton design
Ajouter un nouveau type de véhicule (ex : Scooter électrique) sans réécrire tout le code.
Déplacer une règle métier au bon endroit, dans la bonne classe.
Comprendre quand préférer la composition à l’héritage.
Résultat : un code plus prévisible, plus facile à maintenir, et où tu sais exactement dans quelle classe mettre chaque règle métier.
Plutôt que de manipuler des “Animal / Chien / Chat” vus mille fois, on travaille sur un cas concret de dev métier : la gestion d’une flotte de véhicules.
Ce qu’on construit ensemble :
Une classe de base CL_Vehicule qui tient la route sur la durée.
Des dérivées CL_Voiture, CL_Camion, CL_Moto avec leur logique propre.
Un exemple d’évolution : ajout d’un CL_ScooterElectrique sans tout casser.
Une procédure de test qui parcourt une liste de véhicules et montre le comportement réel de l’héritage.
Tu repars avec un modèle que tu peux réutiliser tel quel ou adapter pour tes propres projets (interventions, documents, utilisateurs, équipements, etc.).
une couche IHM (fenêtres)
une couche métier orientée objet (les classes de véhicules)
une couche Repository pour l’accès aux données.
Ce n’est pas du MVP strict, mais ça en reprend l’idée centrale : l’IHM est maigre et la logique métier est dans les classes.