[POO] Auriez-vous un conseil pour la création de class ?

Bonjour,

Je souhaite faire evoluer mon programme et créer des class pour gerer mes objets.

Je m'explique j'ai des étudiants et je gére les notes les absences etc... aujourd'hui j'ai créer des class(objets) pour gérer plein de chose mais pas les étudiants.

je pense a la chose suivantes: Une class personne et ensuite je créer une autre class qui herite de la class personne (un etudiant peut être une sous class de personne)

Mon problème c'est que je ne maitrise pas du toutes ces notions et je sollicite de votre part de petits conseils pour la création de la class etudiant.

PS: aujourd'hui le programme marche et opérationelle (gestion des notes,absences, etc....) mais le principe POO n'existe pas vraiement pour les les étudiants.
voila comment je vois le code (je résume)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

TPersone = Class Private FIDpersonne :Integer; FNom :String; procedure SetNOM(Value:string); procedure GetNOM:string; Fprenom:String; Fasdresse:String; etc.... Public Constructor Create;virtual; procedure Valider;Virtual; procedure Supprimer;Virtual; property NOM:string read FNom write SetNOM; property prenom......; property adresse.....; procedure...... end;

---

Ensuiste une class Tetudiant qui hérite de la class Tpersonne :

Soit

Class Etudiant

Code:

---

1 2 3 4 5 6 7 8

TEtudiant = Class(TPersone) FAbsence : Array[1..1000] of Tabsence ; FNote : Array[1..1000] of TNote ; ...... private Public   end;

---

Class Absence

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Tabsence = Class FIDpersone:Integer; Fdate:Tdate FJustifier:Integer; Fmatiere:Integer ...... Private Public Procedure Valider;   end

---

Class note

Code:

---

1 2 3 4 5 6 7 8 9 10 11

TNote = Class FIDpersone:Integer; Fdate:Tdate Fnote:Double; Fmatiere:Integer ...... Private Public Procedure Valider end

---

Pouvez-vous me dire si ces strutures vous semblent cohérentes sinon pouvez-vous me conseiller

Cordialement
Qays

J'ai survolé, premier conseil remplace les tableaux par des TObjectList qui te géreront tes libérations des objets listés ... si pour l'ensemble cela me semble correcte, pas contre vérifie si ton virtual sur le constructeur est justifié, ainsi que sur les autres ...

Salut,
ça m'a l'air d'être très bien tout ça !

Néanmoins, voici quelques conseils :
- Place les variables de classe après le private comme dans TPersonne.
Par exemple, au lieu de ceci :

Code:

---

1 2 3 4 5 6 7 8

TEtudiant = Class(TPersone) FAbsence : Array[1..1000] of Tabsence ; FNote : Array[1..1000] of TNote ; ...... private Public   end;

---

Tu devrais avoir ceci :

Code:

---

1 2 3 4 5 6 7 8

TEtudiant = Class(TPersone) private FAbsence : Array[1..1000] of Tabsence ; FNote : Array[1..1000] of TNote ; ...... Public   end;

---

En général, ce qui est placé avant le private, ce sont les objets (les champs) générés par Delphi lors du design d'une fiche par exemple.
C'est pas interdit hein, c'est juste une suggestion de présentation... ;)

Prend l'habitude de déclarer et un constructeur et un destructeur, même si tu ne mets rien dedans ! Comme ça, si il te venait à l'esprit de gérer la construction et la destruction de sous-objets lors d'une évolution de ton programme...

Voici en gros l'allure minimale d'une classe

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

TMachin=class private Ftruc: integer; procedure Settruc(const Value: integer); public //Constructeurs et destructeurs sont publiques constructor Create; destructor Destroy; override; property truc:integer read Ftruc write Settruc; end;   ... constructor TMachin.Create; begin   end;   destructor TMachin.Destroy; begin   inherited destroy; //On appelle toujours le destructeur ancetre end;

---

Imaginons que je souhaite y rajouter un TStringList :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

TMachin=class private Ftruc: integer; FLignes:TStringList; procedure Settruc(const Value: integer); public constructor Create; //Après le constructor on ne met pas de override destructor Destroy; override; //Après le destructor, si property truc:integer read Ftruc write Settruc; end;   ... constructor TMachin.Create; begin FLignes:=TStringList.Create; //création du TStringList end;   destructor TMachin.Destroy; begin FLignes.Free; inherited destroy; end;

---

Sinon, dans ton ide, si tu es en train d'écrire une classe, tu commences par écrire les propriétés de ta classe comme ceci :

Code:

---

1 2 3 4 5 6

TMachin=class private public property truc:integer; property machin:integer; end;

---

De là, tu places ton curseur devant le mot "property", et tu fais "[Ctrl]+[Shift]+C" , et hop, Delphi écrit le reste pour toi :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

TMachin=class private Fmachin: integer; Ftruc: integer; procedure Setmachin(const Value: integer); procedure Settruc(const Value: integer); public property truc:integer read Ftruc write Settruc; property machin:integer read Fmachin write Setmachin; end; ...   { TMachin }   procedure TMachin.Setmachin(const Value: integer); begin Fmachin := Value; end;   procedure TMachin.Settruc(const Value: integer); begin Ftruc := Value; end;

---

Tu souaites rajouter une procedure ou une fonction ou un constructeur ou un destructeur ?

Tu commence par écrire la base de ta réflexion :

Code:

---

1 2 3 4 5 6 7

TMachin=class private procedure CalculeMoyenne(a,b:real); public constructor Create; destructor Destroy; override; end;

---

puis un petit coup de "[Ctrl]+[Shift]+C"....

c'est tout

Bonjour,

quelle est la structure générale du programme ?

où sont stockées les données ? comment sont-elles chargées et enregistrées ? parceque c'est bien d'avoir des classes pour tout, mais il faut bien conserver les infos à un moment donné :D

j'ajoute des commentaires dans ton code...

Citation:

---

Envoyé par QAYS

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24

TPersone = Class Private FIDpersonne :Integer; FNom :String; procedure SetNOM(Value:string); procedure GetNOM:string;   // quel est l'intéret de des deux fonctions ci-dessus ?!   Fprenom:String; Fasdresse:String; etc.... Public Constructor Create;virtual; procedure Valider;Virtual; procedure Supprimer;Virtual; property NOM:string read FNom write SetNOM;   // la syntaxe ci-dessus est suffisante ;)   property prenom......; property adresse.....; procedure...... end;

---

Ensuiste une class Tetudiant qui hérite de la class Tpersonne :

Soit

Class Etudiant

Code:

---

1 2 3 4 5 6 7 8 9 10 11

TEtudiant = Class(TPersone) FAbsence : Array[1..1000] of Tabsence ; FNote : Array[1..1000] of TNote ;   // là encore tout dépend du stockage, mais // je verrais bien une liste chainée ou un objet liste (TList ou TListObject) ...... private Public   end;

---

Class Absence

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Tabsence = Class FIDpersone:Integer;   // qu'apporte l'IDPersonne ici ?   Fdate:Tdate FJustifier:Integer; Fmatiere:Integer ......   // pour une liste chainée, il suffit d'ajouter un champ comme ci-dessous FSuivante:TAbsence; // celui pointe sur l'absence suivant ou a pour valeur "nil"   Private Public Procedure Valider;   end

---

Class note

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

TNote = Class FIDpersone:Integer; Fdate:Tdate Fnote:Double; // vous avez de sacrés notes pour vos étudiants :D Fmatiere:Integer // je suis un peu surpris par ce mélange d'indexe et de classe // pourquoi ne pas avoir une classe TMatiere :D ...... Private Public Procedure Valider end

---

Pouvez-vous me dire si ces strutures vous semblent cohérentes sinon pouvez-vous me conseiller

Cordialement
Qays

---

Bon alors, sinon j'ai l'impression que toutes ces classes ne sont pas vraiment des objets...mais des juste des structures...mais c'est peut-être une fausse impression :D

je m'explique, pour gérer ton problème on peut très bien partir dans une structure objet, mais je la verrais plus sous la forme suivante:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

type TEtudiant=class;   TClasse=class public // fonction d'ajout d'un etudiant procedure NouvelEdution(const Nom:string):TEtudiant; // retrouve un étudiant function TrouveEtudiant(cosnt Nom:string):TEtudiant; // supprimer un étudiant de la classe function Exclure(Etudiant:TEtudiant):boolean; // fonction d'ajout d'un etudiant déjà créé procedure Inscrire(Etudiant:TEtudiant); function EstPresent(Etudiant:TEtudiant):boolean; procedure EstAbscent(Etudiant:TEtudiant); // et bien sur ! procedure Sauvegarder; end;   TEtudiant=class public function EstPresent(Date:TDateTime):boolean; procedure EstAbscent(Date:TDateTime); procedure Noter(Devoir:TDevoir; Note:cardinal); function MoyenneGenerale:single; end;

---

je n'ai mis que la partie publique, en fait ça pourrait même être des Interfaces qui te donne toute la logique entre les objets, et ensuite tu peux les implémenter de différentes façon, sur du fichier texte, une base SQL, en réseau etc... :D

En fait ça pourrait être un Défi Delphi intéressant :D

Merci à tous de vos contributions qui me semblent très intérressantes.

En fait pour résumé le problème je "débute" :oops: en POO, et je souhaite rendre mon projet plus claire, plus sure et plus portables.

Mon programme existe aujourd'hui (il est opérationnel) mais les notions POO ne sont pas vraiement appliquer dans ce dernier.

Mon problème c'est que je ne maitrise pas bcp d'où mon message, je vais donc etudier toutes vos remarques et voir ce que je peux faire

Petite précision ShaiLeTroll me recommendr d'utiliser TObjectList, aurriez-vous un exemple ?

Encore une fois merci
PS: je laisse ouvert la discussion pour avoir d'autre remarque

Je n'ai pas d'exemple du la TObjetList de bonne qualité sous la main, j'ai ceci que je viens d'écrire pour un autre sujet sur le forum, je fais une TObjectList qui contient la liste des fenêtres créés par le programme et s'occupe de les libérer toute d'un coup

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

var _FormManager: TObjectList = nil; _FormManagerInstanceCount: Integer = 0;   procedure CreateFormManager(); begin Inc(_FormManagerInstanceCount); if not Assigned(_FormManager) then _FormManager := TObjectList.Create(); end;   procedure AddToFormManager(const Form: TForm); begin if Assigned(_FormManager) then _FormManager.Add(Form); end;   procedure RemoveToFormManager(const Form: TForm); begin if Assigned(_FormManager) then _FormManager.Remove(Form); end;   procedure FreeFormManager(); begin Dec(_FormManagerInstanceCount); if (_FormManagerInstanceCount = 0) and Assigned(_FormManager) then _FormManager.Free(); end;

---

Sinon, la POO, n'est qu'une façon de faire, comme il a été souligné, nous ne savons pas comment tu stockes tes données, et si c'est un BD classique, tes objets ne seront que des encapsulations de DataSet avec bcp de code pour peu d'efficacité (pour ton volume de données, cela ne se verra pas)... je pourrais apporter des idées à ce sujet, ayant écrit une couche de persistance au bureau (pas aussi poussé et abstraite que InstantObjects), mais cela t'encombrerait les idées pour rien ... la POO peu se faire sans objet, il suffit d'architecturer son code par unité qui regroupe les fonctionnalités sur une table donnée ... la programme objet ce n'est que la fusion des Structures et des Traitements en un seul bloc ... bcp d'anciens programmeur faisait de l'objet avant que cela existe juste en ayant de la rigueur dans la programmation, en ne mélangeant pas la gestion écran (mode texte) et la manipulation de données dans une même unité...

Voici comment je pense faire :

Dans la class Tedudiant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

Unit Uetudiant;   TEtudiant = Class(TPersone) FAbsence : Array[1..1000] of Tabsence ; FNote : Array[1..1000] of TNote ; private Public procedure Valider; Constructor Create(Owner:Tcompoent);   end;   Constructor Create(Owner:Tcompoent); begin inherited; Notes_etudiant := TNote.Create(self); Ansence_etudiant := TAbsence.Create(self); etc..... end;   end.

---

ensuite l'utilisation de cette class

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

Unit Unit1 ; Tform1 = Class(Tform) blablabla end   Var Etudiant:Tetudiant;   Implementation uses .....   procedure Tform1.bntClick(sender:Tobject); begin Etudiant:=Tetudiant.Create(sender); end   procedure Tform1.Valider(sender:Tobject); begin Etudiant.idpersone := StrToInt(edit3.text); Etudiant.nom := edit1.text; Etudiant.prenom := edit2.text; etc... Etudiant.Valider Notes_etudiant. ????? Boom c'est là que je pèche. end; end.

---

en effet dans ma version actuelle j'ai un tableau de note pour un étudiant.
comment faire là.

Citation:

---

Tabsence = Class
FIDpersone:Integer;

// qu'apporte l'IDPersonne ici ?

---

Cela me permets d'alimenter ma base de données(table absences clé idpersonne).

Cordialement
Qays

Citation:

---

la POO peu se faire sans objet, il suffit d'architecturer son code par unité qui regroupe les fonctionnalités sur une table donnée ... la programme objet ce n'est que la fusion des Structures et des Traitements en un seul bloc ... bcp d'anciens programmeur faisait de l'objet avant que cela existe juste en ayant de la rigueur dans la programmation, en ne mélangeant pas la gestion écran (mode texte) et la manipulation de données dans une même unité...

---

C'est que qui est fait actuellement (dans ala version de production, celle qui tourne dans une école).

En fait j'ai extrernaliser bcp de fonctinnalité et de Unit, pour gérer mes projets informatique (accès bdd, gestion des menus, gestion des écrans) mais j'ai voulue essayer de gèrer mes étudiant et autre objets(messagerie, calendrier, bloc-notes, carnet d'adress) à l'aide de la POO.

Cordialement
merci de votre diligence.

je pense qu'il ne faut pas faire de la POO pour faire de la POO

j'ai longtemps programmé en Pascal avec du pur procédural. La notion d'unité du Pascal est d'ailleurs parfaitement adaptée pour cela, elle permet même de gérer la notion de singleton (1 unité = 1 objet unique).

bon, là ça dois faire dans les 15 ou 20 ans que je fais du Pascal, donc je suis aller un peu plus loin qu'à mes débuts, et la POO m'apporte effectivement beaucoup de chose maintenant...mais contrairement à d'autres, je n'hésite pas à revenir au procédural quand c'est plus simple :D

d'ailleurs pour dire la vérité, je commence toujours pas du procédural avec des records...quand le code devient trop pénible à gérer avec des Records, je passe aux classes. La limite entre les deux est assez simple, je passe à l'objet quand je désire invoquer une méthode pour mon record :D

prenons mon serpent 3D par exemple :)

j'aurais très bien pu créer un tableau de 16*16 éléments (taille maximum du serpent) pour gérer chaque "anneau" du serpent.

j'aurais pu aussi créer une liste chainée d'élements

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

type PAnneau=^TAnneau; TAnneau=record x,y:integer; Next:PAnneau; end;   var Anneaux:PAnneau;   procedure DessineSerpent; var a:PAnneau; begin a:=Anneaux; while a<>nil do begin DessineAnneau(a); a:=a.Next; end; end;

---

et là on voit de suite qu'on pourrait écrire "Anneau.Dessine"...sur cet exemple ça ne nous apporterait vraiment pas grand chose, mais pour un record plus complexe qui va nécessiter des tas de tests, ça va vite nous pourrir la vie...donc pas d'hésitation, on crée un objet avec des méthodes et des propriétés :D

J'en reviens à nos étudiants, tant qu'il sagit de stocker des informations sur l'étudiant, un record suffit largement, mais il devient plus simple de faire de l'objet quand l'Etudiant possède des caractèristiques

Code:

---

1 2 3 4 5 6 7 8 9 10

procedure TEdudiant.Bulletin(List:TStrings); var i:integer; begin for i:=0 to fDevoirs.Count-1 do begin if EstPresent(fDevoirs[i].Date) then List.Add(fDevoirs[i].Name+'='+NotePour(fDevoirs[i].ID); end; end;

---

ici fDevoirs, EstPresent et NotePour sont une propriété et des méthodes de l'objet qui rend le tout plus simple à comprendre qu'avec un truc genre

Code:

---

1 2 3 4 5 6 7 8 9 10

procedure Bulletin(EtudiantID:integer; List:TStrings); var i:integer; begin for i:=0 to Etudiants[EtudiantID].NombreDevoirs-1 do begin if EstPresent(EdutiantID,Etudiants[EtudiantID].Devoirs[i].Date) then List.Add(EdutiantID,Etudiants[EtudiantID].Devoirs[i].Name+'='+NotePour(EdutiantID,Etudiants[EtudiantID].Devoirs[i].ID); end; end;

---

bon, ok, un ou deux WITH simplifierait l'écriture... mais pas forcément la compréhension du tout :D

merci, en fait vous me rassurer, sur ma methode (de programmation).

ps: votre exemple mais bien expliquer quand utiliser la POO et quand ne pas l'utiliser.

Voila maintenant près de 5 ans que je fais du delphi et rarement j'ai utilisé la POO, que lorsque j'en avait vraiement besoin , je vais donc continuer comme je fais actullement et utiliser la POO quand cela sera vraiement utile (gestion d'accès aux bases de données, gestion de menu, d'écran etc..)

Cordialement
Qays.