Discussion :

[looping]

Bonjour

J'ai un doute sur la position de la déclaration des variables globale à une unité:

J'ai toujours fait comme dans l'exemple ci-dessous: je les déclare dans l'implémentation:
var
ident_bl:integer;

Mais certain tuto disent de les mettre dans l'interface (que j'ai nommé ICI dans le code ci dessous)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
   .................................

    procedure DBCtrlGrid1DblClick(Sender: TObject);
    procedure FormShow(Sender: TObject);
  private
  <ICI>
    { Déclarations privées }
  public
  procedure Edit(PartNo,Nobl:integer);
 < ICI>
    { Déclarations publiques }
  end;

var
  Form71: TForm71;
 < ICI>
	

implementation
         uses dmunit,unit3;
{$R *.dfm}

var
ident_bl:integer;

------------

Quel est la meilleure solution ?

Cordialement

[fred1599]

Hello,

La meilleure pratique dans votre cas n'est ni dans l'implémentation, ni dans l'interface, mais de déclarer votre variable comme un champ privé de votre classe de fiche TForm71.

À mon sens, implementation mieux que interface, car au moins la variable est cachée aux autres unités.

Si interface, cela rendrait votre variable globale à toute l'application -> fortement déconseillé

[popo]

Cela dépend de la portée nécessaire.

Si votre variable est propre à la classe TForm71 mais doit pouvoir être accessible en dehors.
Alors il vaut mieux la déclarer dans la section public de la classe.
Au passage, il serait préférable de renommer cette classe.

Si votre variable est propre à la classe TForm71 mais n'a pas besoin d'être accessible en dehors.
Alors il vaut mieux la déclarer dans la section private de la classe.
Ou potentiellement dans la partie protected si vous faite de l'héritage de fiche.

Déclarer une variable dans la partie interface revient à la rendre accessible et surtout modifiable de partout.
C'est rarement nécessaire et souvent dangereux car plus le code est maintenu par beaucoup de monde et grossit, plus il devient difficile de maitriser ce qui est fait avec cette variable globale.
C'est pourquoi, c'est généralement déconseillé.

Déclarer une variable dans la partie implémentation revient à la rendre accessible modifiable uniquement dans l'unité où elle se trouve.
C'est parfois nécessaire (moi je m'en suis servi en Delphi 7 pour implémenter un singleton).
Mais, ça demande réflexion.

[anapurna]

Salut

si tu veux une variable global à toute ton application
tu peux aussi passer par une objet (exemple TGLobalParam) qui se lance automatiquement
et est accessible de tous

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Unit UParams;
Interface 
  ... 
TGlobalParams = CLass(...)
  Param1 : Integer
  Param2 : String
...
End;
Var
   GlobalParams : TGlobalParams; 
Implementation
 
TGlobalParams.Create(....
...
End;  
 
initialization
  GlobalParams := TGlobalParams.Create;
 
finalization
  GlobalParams.Free;
 
end.

dans le corps de tes form tu n'auras plus qu'a faire par exemple

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
  ...
   GlobalParams.Param1 := GlobalParams.Param1 + 1;
   ...

Pour que cela fonction il te faudra juste ajouter l'unité dans les uses

[popo]

anapurna, je suis désolé mais je ne suis pas d'accord avec toi sur cette solution, en tout cas pas dans la manière dont tu l'as implémenté.

Là tu as une variable globale qui est un objet que rien ne protège.
Quelqu'un pourrait la libérer, créer une autre instance et de fait réinitialiser les valeurs.

L'idée d'une classe de paramètre ne me choque pas.
C'est la manière dont elle est implémentée qui me dérange.

[anapurna]

Salut

au dernière nouvelle c'est nous qui gérons notre programme
(création et destruction d'objet)
Donc nous savons normalement ce que nous faisons avec les Objet

Une variante c'est de mettre en place des getter et des setter pour protéger les variables

je ne fournis qu'un alternative a la variable global afin d'avoir une méthode rapide pour avoir des variables globale a ton programme
voici donc une version plus plus élaboré

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
TGlobalParams = CLass(...)
  Private 
  fParam1 : Integer
  fParam2 : String
...
  Protected 
    Function GetParams1 : Integer; 
    Procedure SetParams1(I1 : Integer);
  Public   
   Procedure IncParam1;
  Published 
   Property Param1 : Integer Read GetParams1 write SetParams1 
   Property fParam2 : String Read GetParams2 write SetParams2 
End;
  ...
  Function TGlobalParams.GetParams1 : Integer; 
  Begin 
     Result := Fparams1;
  End;
  Procedure TGlobalParams.SetParams1(I1 : Integer);
  Begin 
     Fparams1 := I1;
  End;

sur le principe cela ne change rien
c'est juste un accès global a une propriété d'un objet dédié dans ton programme

Moi ce que je ne comprend pas c'est de qui tu parle quand tu dis "que rien ne protège.
Quelqu'un pourrait la libérer, créer une autre instance et de fait réinitialiser les valeurs."

Mis a part les développeurs et ou les hacker à la limite je vois pas bien qui peut réinitialisé l'objet

[popo]

Mis a part les développeurs et ou les hacker à la limite je vois pas bien qui peut réinitialisé l'objet

Un développeur justement.
Un nouveau, ou un qui serait fatigué et ferait la boulette.
Le tout dans une livraison où l'erreur est cachée au milieu d'une pléthore d'autres modifications.

Une variante c'est de mettre en place des getter et des setter pour protéger les variables.

Mettre un setter qui se contente d'affecter la valeur n'apporte pas grand choses à la version précédente.
Tu as ajouté une complexité inutile.

Et ce n'est pas l'accès à la propriété le problème.
Le problème vient du fait que rien n'empêche un développeur mal réveillé de libérer ton objet ou de le remplacer par mégarde.

La solution la plus simple pour éviter ça, mais il y en a d'autres est d'accéder au données de ton objet via une interface.
Une simple fonction renvoyant un IGlobalParams.
La variable GlobalParams est déclarée dans la partie implémentation où il n'est pas accessible.

[ShaiLeTroll]

Sinon plus simple, lire le tutoriel Implémentation d'un Singleton avec Delphi 7 où ce débat a déjà eu lieu avec la reprise d'un concept simple : III. Utilisation d'une fonction globale que tout le monde connait dans Delphi avec la function Printer qui est un exemple de Singleton historique de Delphi (mieux encore que Application)

Et ce tutoriel, cela ne concerne que D7, avec Popo, on avait échangé sur l'utilisation de Générique pour introduire un code réutilisable voire même ThreadSafe dans le sujet lié au Tutoriel : Implémentation du Singleton avec Delphi 7, par Jérémy Laurent



Sinon, attendez plutôt la réponse de looping pour savoir la portée de sa variable, son cas d'utilisation, à mon avis, il est perdu dans ce sujet plus complexe que prévu pour lui.

[ALWEBER]

Tu mets les variables dans l'interface si tu les utilises depuis plusieurs unités. Dans la partie implémentation sinon
Le positionnement des uses est aussi important. Si deux unités unit1 et unit2 s'utilisent mutuellement alors le "uses unit1"se met dans la partie interface de unit2 ]et le "uses unit2" se met dans la partie implémentation de unit1 ou inversement.

[ShaiLeTroll]

Pour illustrer le propos de ALWEBER, autant reprendre la démo de Paul Toth, c'est idéal pour commencer, une unité dédié à la variable globale, c'est isolé, simple et c'est le uses qui rend l'accès possible.

Surtout que looping lui ne voulait qu'un simple champ "integer".

Et le plus important, ce n'est pas le code mais le "pourquoi une variable globale à une unité ?", looping doit estimer la durée de vie de "Ident_BL" et sa portée, une fois cela posé, la réponse sera naturelle et surement plus simple (celle de fred1599)

un champ private sera l'idéal, Ident_BL genre le numéro en cours d'un "Bon de Livraison"

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 private
    { Déclarations privées }
    FIdent_BL: Integer;

DBCtrlGrid1, unit3, TForm71 ... à renommer !
L'extrait est très révélateur qu'il faut répondre au plus simple.

[Andnotor]

La question originale a été répondue : en fonction de la portée.

Et si on veut regrouper des paramètres globaux sans possibilité de mauvaise manipulation ; on reste dans le statique en passant par un record, pas une classe.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
type
  TParams = record
  private
    ...
  public
    property Param1 :integer read FParam1;
    property Param2 :integer read FParam2;
  end;
 
var
  Params :TParams;