Débuter avec la Programmation Orientée Objet

Salut
J'ai envie d'optimiser un programme écrit en Lazarus en utilisant les classes. J'ai lu un bon nombre de tutoriels sur la POO mais je suis confronté à un problème, à savoir dans quel projet (programme, console d'application...) ou encore dans quel module (unit, ..) dois-je écrire mes classes.
Je vous remercie.

Dans une unité que tu créeras et dont tu choisiras toi-même le nom. :)

Bonsoir,

Dans certains cours sur la POO, il est conseillé :
- de créer une unité pour chaque classe,
- de donner le même nom à l'unité et à la classe qui lui correspond, le premier étant préfixé par U et le second par C,
- d'éviter de mélanger dans une même unité la programmation procédurale et la programmation orientée objet.

Ces mesures simples permettent généralement une meilleur lisibilité du code.

Bonjour

Et pour répondre "à quel projet (programme, console d'application...)", je dirais que c'est totalement indépendant de ton style de programmation. Tu peux faire une application console en POO...

Le plus courant c'est cependant Projet, Application avec une fiche pour commencer, à quoi tu ajoutes des Unités pour tes classes.

Merci à tous.
Je vais combiner vos explications pour avoir un bon résultat.

Citation:

---

Envoyé par Modulpro

Bonsoir,

Dans certains cours sur la POO, il est conseillé :
- de créer une unité pour chaque classe,
- de donner le même nom à l'unité et à la classe qui lui correspond, le premier étant préfixé par U et le second par C,
- d'éviter de mélanger dans une même unité la programmation procédurale et la programmation orientée objet.

Ces mesures simples permettent généralement une meilleur lisibilité du code.

---

Personnellement j'utilise une autre approche, qui est celle de la VCL

l'unité Forms, déclare TForm.

donc si je veux créer des classes d'élèves, ce sera l'unité Eleves qui déclare TEleve.

par contre je ne me limite pas à une classe par unité, notamment pour ne pas tomber dans des problèmes de référence circulaires.

EDIT: et je n'hésite pas à mélanger code procédural et objet, ou plus exactement à regrouper ce qui va ensemble.

exemple:

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 30

unit Abouts;   interface   uses Forms;   type TAbout = class(TForm) ... end;   procedure ShowAbout;   implementation   procedure ShowAbout; begin with TAbout.Create(Application) do begin try ShowModal(); finally Free; end; end; end;   end.

---

Tout à fait d'accord.

Dans le même genre : je crée une fiche générique, disons, TChooseFileForm, genre mini-explorateur, pour choisir une liste de fichiers de tel ou tel type : eh bien, les fonctions globales ChoosePictures, ChooseTexts, etc.. qui utiliseront cette fiche, seront déclarées dans la même unité.

Deuxième exemple : si on veut utiliser l'héritage de façon rigoureuse dans Delphi ou Lazarus, avec des méthodes déclarées dans la partie protected, on n'a pas le choix : les descendants doivent aussi être déclarés dans la même unité.

Troisième exemple : je crée un descendant de TList, TListOfTruc, conçu pour manipuler des objets TTruc. TTruc et TListOfTruc seront déclarés eux aussi dans la même unité. C'est de toute façon bien plus efficace dans la conception du code.

Il est rarissime que j'aie écrit des unités ne déclarant qu'un seul type d'objet. Moi aussi, je mets ensemble ce qui va ensemble.