Salut;
j'aimerais savoir pourquoi un membre déclaré dans la section private d'une classe est visible dans son unité ?
NB : j'utilise Delphi 7.
Merci à vous.
Salut;
j'aimerais savoir pourquoi un membre déclaré dans la section private d'une classe est visible dans son unité ?
NB : j'utilise Delphi 7.
Merci à vous.
tu dois penser à ce type de code :
je pense que ça réserve la faculté de déclarer 2 types dans la même unité dont l'un manipulera des champs d'une instance de l'autre sans passer par des setters/getters, le programmeur ayant fait le choix de ne pas les déclarer dans 2 unités, du fait d'une complémentarité, et dans un souci de rapidité
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 procedure TTest.Show; begin ShowMessage(IntToStr(FField)); // champ de TTest Form1.FFormField:=-1; // champ privé de Form1, accessible car TForm1 déclaré dans la même unité end;
mais libre à lui de les isoler dans des unités distinctes... il peut y avoir danger, effectivement. cependant, les descendants déclarés dans une autre unité qui surchargeront des procédures perdront cet accès
Sans grand intérêt alors. C'est pour ça je me pose cette question sans être vraiment être convaincu des réponses que j'ai eu. En suivant les règles d'une bonne POO ça parait comme une violation, non !
Disons qu'en Delphi, c'est la seule façon de mettre en oeuvre le concepte de "classes amies" qu'on retrouve en POO.
Une classe amie est une classe qui peut accéder aux membres privées d'une autre. Ca sert lorsque tu utilises plusieurs classes pour résoudre un seul et même problème, que certaines classes ont besoins d'avoir accès à des méthodes d'une autre, mais que tu ne veux pas que c'est dernières soient publiques et accessibles par n'importe qui.
On retrouve également ce concept sous la forme de la visibilité "package" de Java, ou la visibilité "Internal" de .NET
Maintenant en Delphi, tu as la visibilité Private qui est en réalité visible par la classe et toutes les classes déclarées dans la même unité.
Ainsi que la visibilité "strict private" qui est un private pur et dur, inacessible par les autres classes.
Après c'est comme tout. Tu peux t'en servir pour faire du code plus propre, ou au contraire pour faire n'importe quoi !
C'est une approche plus pragmatique, le problème est que Delphi n'est pas un langage OO conçu "from scratch", des compromis ont été choisis lors de sa conception, il fallait conserver certaines caractéristiques du Pascal, ce qui interdisait sans doute un compilateur trop strict. Ce qui lui donne aussi une certaine souplesse.
Remarquez que Delphi est un langage assez âgé micro-informatiquement parlant, il est sorti en 1995, les développeurs de l'époque n'étaient pas forcément des crack de la POO mais cela a permis le développement d'un grand nombre d'applications.
Si tu veux un langage mieux conçu mais moins ouvert à la bidouille et aux petits arrangement, tourne-toi vers Eiffel.
Cdlt
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager