3.3Programmation orientée objet (classes) en WLangage
L'essentiel en 30 secondes
- La classe est le modèle, l'objet l'exemplaire : les membres portent les données, les méthodes les traitements, le constructeur initialise.
- L'encapsulation protège les données sensibles derrière des méthodes ; l'héritage spécialise un socle commun sans duplication.
- La POO n'est pas obligatoire : Yacine l'utilise pour les règles métier riches et les variantes de clients, pas par principe.
Mini-cas filé — Yacine modélise clients et encours
Yacine gère les clients de la PME de négoce de matériel électrique à Oran : particuliers, entreprises et installateurs. Jusqu'ici, il promenait des variables éparses et des conditions partout pour calculer un encours et vérifier la solvabilité. Il crée une classe Client avec un constructeur, un membre d'encours et une méthode EstSolvable. Puis il fait hériter ClientEntreprise de Client pour ajouter un plafond négocié, sans dupliquer le socle. Les membres sensibles ne sont plus modifiés directement : tout passe par EnregistreFacture et EstSolvable. Yacine garde cependant ses procédures de calcul simples en dehors des classes : il note le réflexe : POO là où elle clarifie, pas systématiquement.
Cas autonome de cette section : il revient dans le cours, le schéma, le script et le défi 48h de la section 3.3.
1. Classe, objet, membres et méthodes
La programmation orientée objet organise le code autour d'objets qui regroupent des données et les traitements associés. La classe est le modèle, le plan de construction : la classe Client décrit ce qu'est un client et ce qu'on peut faire avec. L'objet, ou instance, est un exemplaire concret créé à partir de cette classe. Les membres sont les données de l'objet — nom, encours — et les méthodes les procédures qui agissent sur elles. Le constructeur est appelé automatiquement à la création pour initialiser l'objet.
2. Encapsulation, héritage, polymorphisme
L'encapsulation regroupe données et traitements et protège l'accès direct aux données : on passe par des méthodes, ce qui garantit le respect des règles. L'héritage crée une classe à partir d'une autre en récupérant ses caractéristiques et en les spécialisant : ClientEntreprise hérite de Client et ajoute son plafond négocié sans dupliquer le socle. Le polymorphisme permet d'appeler la même méthode sur des objets différents, chacun réagissant selon sa classe.
3. POO utile, pas obligatoire
La POO brille pour les applications complexes, les règles métier riches, le code destiné à être réutilisé et le travail en équipe. Mais elle n'est pas obligatoire : une application de gestion classique se développe très bien en procédural, avec des procédures bien organisées en collections. Le pragmatisme prime. Yacine utilise une classe quand un concept porte vraiment des règles et un état cohérent — un client avec son encours — et garde de simples procédures pour les calculs isolés.
🔎 Exemple concret — 🔎 Exemple concret — Une classe Client qui protège son encours
Yacine encapsule l'encours et le contrôle de solvabilité dans la classe :
Client est une classe
m_sCode est une chaine
m_sNom est une chaine
m_nEncours est un monetaire
PROCEDURE Constructeur(sCode est une chaine, sNom est une chaine)
m_sCode = sCode
m_sNom = sNom
m_nEncours = 0
FIN
PROCEDURE EnregistreFacture(nMontant est un monetaire)
m_nEncours = m_nEncours + nMontant
FIN
PROCEDURE EstSolvable(nPlafond est un monetaire) : booleen
RENVOIE m_nEncours <= nPlafond
FIN
FIN
cClient est un Client("CLI042", "Dupont Materiel Electrique")
cClient.EnregistreFacture(12500)
SI PAS cClient.EstSolvable(20000) ALORS
Info("Encours depasse : relance commerciale")
FINLecture : l'encours ne se modifie que par EnregistreFacture, jamais directement.
Leçon : la règle de solvabilité voyage avec la donnée qu'elle concerne.
Vocabulaire de la section
- Classe
- Modèle décrivant les données et les traitements d'un concept, à partir duquel on crée des objets.
Exemple simple : La classe Client décrit le code, le nom, l'encours et les méthodes associées.
Ce que ce n'est pas : un objet concret comme le client Dupont.
Réflexe : le plan d'un concept → la classe.
- Objet (instance)
- Exemplaire concret créé à partir d'une classe, avec ses propres valeurs de membres.
Exemple simple : cClient est une instance de Client pour Dupont Matériel Électrique.
Ce que ce n'est pas : le modèle Client qui n'a pas encore de valeurs.
Réflexe : un exemplaire utilisable → un objet.
- Encapsulation
- Protection des données d'un objet derrière des méthodes qui garantissent les règles.
Exemple simple : L'encours ne change que via EnregistreFacture.
Ce que ce n'est pas : un membre modifiable directement depuis n'importe quel écran.
Réflexe : donnée sensible → encapsulation.
- Héritage
- Création d'une classe à partir d'une autre en récupérant son socle et en le spécialisant.
Exemple simple : ClientEntreprise hérite de Client et ajoute un plafond négocié.
Ce que ce n'est pas : recopier tout le code de Client dans une seconde classe.
Réflexe : spécialiser sans dupliquer → héritage.
- Constructeur
- Méthode appelée automatiquement à la création d'un objet pour l'initialiser.
Exemple simple : Le constructeur de Client fixe le code, le nom et un encours à zéro.
Ce que ce n'est pas : un objet créé avec des membres non initialisés.
Réflexe : initialiser à la création → constructeur.
En pratique — En pratique — Créer et utiliser une classe
- Créez une classe représentant un concept métier (Client, Commande) avec ses membres et ses méthodes, comme Yacine.
- Ajoutez un constructeur pour initialiser l'objet et protégez les membres sensibles par encapsulation.
- Instanciez un objet et appelez ses méthodes : données et traitements voyagent ensemble.
- Si plusieurs variantes partagent un socle, utilisez l'héritage (ClientEntreprise) plutôt que dupliquer le code.
Script pas-à-pas — modéliser un client comme Yacine (5 min)
1) Identifiez un concept qui porte à la fois des données et des règles (client, commande). 2) Listez ses membres et les méthodes qui doivent les protéger. 3) Écrivez le constructeur pour garantir une initialisation correcte. 4) Instanciez un objet dans un écran et appelez ses méthodes. 5) Si un cas voisin partage le socle, faites-le hériter au lieu de copier le code.
Gardez ce critère : une classe se justifie quand le comportement et les règles méritent de voyager avec les données.
Modèle copier-coller — la fiche POO de Yacine
Classe : modele (donnees + methodes + constructeur)
Objet : instance concrete avec ses valeurs
Encapsulation : proteger les membres sensibles via des methodes
Heritage : specialiser un socle commun sans dupliquer
Pragmatisme : POO si regles riches / variantes / composants ; sinon proceduralUn client entreprise
Yacine fait hériter ClientEntreprise de Client pour ajouter un plafond négocié.
Un encours incohérent
L'encours ne se modifie plus que par EnregistreFacture : la règle est centralisée.
Un calcul isolé
Yacine garde CalculeMontantTTC en procédure : aucune donnée d'état à encapsuler.
Un constructeur oublié
Un objet créé sans initialisation produit un encours absurde : Yacine ajoute un constructeur.
✓ Bonnes pratiques
- Modéliser une classe quand des règles accompagnent les données.
- Protéger les membres sensibles par l'encapsulation.
- Utiliser l'héritage pour spécialiser, pas pour recopier.
✗ Pièges fréquents
- Créer une classe qui ne fait que porter des données.
- Laisser modifier un encours ou un statut directement.
- Vouloir tout objectiser par principe.
Points clés à retenir
- Classe = modèle, objet = instance, membres = données, méthodes = traitements.
- Le constructeur initialise l'objet à sa création.
- Encapsulation et héritage évitent incohérences et duplication.
- La POO est utile mais pas obligatoire : le pragmatisme prime.
Défi 48h — appliquez demain
Comme Yacine, choisissez dans votre application un concept qui porte des règles (client, commande, produit) et créez une classe avec ses membres, un constructeur et deux méthodes. Protégez un membre sensible par encapsulation, puis ajoutez une variante par héritage. Écrivez enfin en une phrase pourquoi vous gardez le reste en procédures : la POO doit clarifier, pas compliquer.
- Je distingue classe, objet, membres, méthodes et constructeur.
- Je comprends encapsulation, héritage et polymorphisme.
- Je sais décider quand la POO apporte de la clarté.
Questions fréquentes
Faut-il utiliser la POO dans un projet WinDev de gestion classique ?
Pas forcément : une application de gestion se développe très bien en procédural structuré, avec des procédures organisées en collections. La POO devient intéressante quand un concept porte des règles riches, quand l'encapsulation est nécessaire, quand plusieurs variantes partagent un socle ou quand le code doit être réutilisé en composant. C'est un outil, pas une obligation.
Quelle différence entre une structure et une classe ?
La structure regroupe seulement des données, sans comportement ni protection : parfaite pour transporter une adresse ou une ligne importée. La classe regroupe données et traitements, avec constructeur, encapsulation et héritage : elle se justifie quand il y a du comportement et des règles à garantir. En cas de doute, commencez par la structure si vous avez seulement besoin de regrouper des informations.
Que regroupe une classe en WLangage ?