Discussion :

[MaTHieU_]

Bonjour,

Je souhaiterai savoir quelles sont les différences entre :
- private : accessible que dans la classe
- public : accessible de partout
- protected : ?
- published : ?

Dans quels cas doit-on mettre des déclarations en protected et published ?

Merci,
MaTHieU_

[sjrd]

• private : accessible dans toute l'unité ;
• protected : accessible dans toute l'unité et dans les classes enfantes ;
• public : accessible partout ;
• published : comme public, mais avec en plus génération de RTTI pour l'exploitation par l'inspecteur d'objet par exemple.

Donc tu peux utiliser protected quand tu veux que certaines données/méthodes soient accessibles par la classe ou ses enfants, mais pas le reste.

Et published c'est seulement quand tu développes un composant, ou dans des cas assez particuliers ou tu veux te servir des RTTI pour tes besoins personnels.

[MaTHieU_]

Merci !

[Clorish]

Je precise quand meme une chose :

Private est plutot limité a la classe elle meme qu'a l'unitee.
Au niveau pratique, on peut y faire appel depuis une autre classe de la meme unitee, mais quand cette fonctionnalitée n'est pas maitrisee, cela entraine des erreurs au niveau conception assez importante.

Donc pour moi, Private doit limité a la classe, et son usage extra-classe ne doit pas se faire sans etre "sur" qu'il n'existe pas d'autre solutions.

[MaTHieU_]

En effet, c'est comme celà que je le vois également.

Merci.

[Pedro]

Salut

Je precise quand meme une chose :

Private est plutot limité a la classe elle meme qu'a l'unitee.
Au niveau pratique, on peut y faire appel depuis une autre classe de la meme unitee, mais quand cette fonctionnalitée n'est pas maitrisee, cela entraine des erreurs au niveau conception assez importante.

Certes, d'où l'existence de strict private

[Clorish]

Salut

Certes, d'où l'existence de strict private

Hu ?!?
Sous D7 ca existe ? ou c'est une invention de D200X+ ?
Pk dans ce cas .... Oust le Private !

[Pedro]

Hu ?!?
Sous D7 ca existe ? ou c'est une invention de D200X+ ?

On n'appelle pas ça une invention mais une évolution

[Paul TOTH]

Je precise quand meme une chose :

Private est plutot limité a la classe elle meme qu'a l'unitee.
Au niveau pratique, on peut y faire appel depuis une autre classe de la meme unitee, mais quand cette fonctionnalitée n'est pas maitrisee, cela entraine des erreurs au niveau conception assez importante.

Donc pour moi, Private doit limité a la classe, et son usage extra-classe ne doit pas se faire sans etre "sur" qu'il n'existe pas d'autre solutions.

je ne suis pas d'accord, Delphi ne connait pas la notion de classe "amie", on DOIT déclarer dans une même unité les classes qui partagent des informations privées que l'on ne veut pas rendre accessible aux descendants

c'est d'ailleurs parfois gênant.

[Clorish]

Tout a fait .... mais le principe de classe amie est reserve a un certain type de programation, et ne doit pas etre employer a la legere.

Partir sur la base que cela est est possible risque d'entrainer de mauvaises habitudes et des erreurs de conceptions quand on ne maitrise pas cette facon de coder.

D'ou mes propos

Mais soit dite en passant, c'est clair que c'est pas clair leur truc
Et franchement contraignant .... et source de bon nombre de references circulaires ...
A moins de tout coder dans le meme fichier pas

[e-ric]

Enfin bref, private en mode "classe amie" n'est pas conseillé mais ça peut servir. Remarquez que cela explique peut-être certains rassemblement de classes dans la VCL. Donc si Borland le fait...(le développement n'est pas un dogme). Ce ne sont que des compromis entre l'idéal et la réalité.

cdlt

[Clorish]

Ce ne sont que des compromis entre l'idéal et la réalité.

Ou une bidouille pour eviter de coder un veritable systeme de classes amies ......

[sjrd]

Ben moi je suis plutôt de l'avis de Paul Toth. Le fait que private soit partagé par toute l'unité, je ne prends pas ça comme une bidouille ou autre workaround par rapport aux classes amies.

C'est simplement une autre philosophie. Et personnellement, j'ai tendance à préférer la façon de voir de Delphi (unité) que du C (classes amies). Une unité est par définition un ensemble d'objets qui sont unis entre eux, et qui peuvent donc se partager des informations "confidentielles".

En fait, si je veux pousser le bouchon, c'est plutôt parce que le C n'a pas le concept d'unité qu'il a dû inventer les classes amies

[Clorish]

En fait, si je veux pousser le bouchon, c'est plutôt parce que le C n'a pas le concept d'unité qu'il a dû inventer les classes amies

C'est effectivement une facon de voir les choses

[e-ric]

Remarquez bien que je ne critiquais pas. Cela ne sert pas à grand chose, le langage ne sera pas changé pour autant. Le problème est tojours de trouver des compromis acceptable et pertinent.

cdlt

[Paul TOTH]

je suis assez d'accord les unités remplacent avantageusement les namespaces

mais faut bien reconnaitre que parfois les références circulaires sont pénibles

tout comme j'aimerais parfois qu'une classe déclarée en INTERFACE face référence à une classe que je ne voudrais pas mettre en INTERFACE, mais uniquement en IMPLEMENTATION...c'est à dire, la garder locale à mon unité...or ce n'est pas possible sauf à utiliser un type générique...ce qui n'est pas non plus très pratique.

en tout cas, j'ai commencé le Pascal avec Turbo Pascal 3 (qui n'avait pas encore les unités) et je ne m'en lasse pas

[e-ric]

J'ai fait mes premières armes en programmation PC avec Turbo Pascal 3 et Lisp mais je ne regrette pas TP3, c'est quand même une autre époque même si ce compilo a représenté un saut technologique en ces temps reculés

Par contre, Delphi, malgré ses limites, est toujours un vrai plaisir.

Cdlt