alternatives aux variables globales

**looping** · 20/03/2013, 19h47

Bonjour,

Partout on lit qu'il ne faut pas utiliser les variables globales.
Mais peut on les éviter ?

Autant je comprends que gerer 50 ou 100 variables globales serait dangeureux , on a quand même besoin de quelques variables qui sont propres à tout le programme.

Dans mon appli en cours, j'ai choisi la méthode de faire une unité globale.pas où sont rassemblés toutes mes variables. J'ai environ 10 variables qui sont pour la plupart des strings représentant des chemin d'accès. Ces variables sont chargés au demarrage de l'appli depuis un fichier .ini propre à chaque utilisateur.

Et vous; comment faites vous pour gerer des données communes à tout le programme , mais qui sont différentes en fonction des utilisateurs?

Merci

**EMC51** · 20/03/2013, 22h12

Bonsoir,

Le .ini ça date un peu.

La base de registre ça sert aussi à cela.

Sinon, selon les cas, pourquoi ne pas utiliser un fichier XML ?...

**Paul TOTH** · 21/03/2013, 05h54

Alors non, les variables globales ce n'est pas "mal", pas plus que les fonctions non-objet ou le code procédural

Ce qui est mal, c'est d'utiliser des variables globales alors quelle ne devrait pas l'être.

Ton exemple d'usage est parfaitement légitime, je fais exactement la même chose, ce sont des valeurs initialisées au lancement du programme qui n'ont pas vocation à changer en cours d'exécution et qui sont utilisées à différents endroit, c'est parfait.

Un exemple de mauvaise utilisation de variable globale, que je rencontre souvent :

Code :

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

1
2
3
4
5
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  Form1.Caption := 'Hello';
end;

la méthode d'instance TForm1.Button1Click se retrouve liée à une instance spécifique Form1 et non l'instance en cours. Alors oui, ça fonctionne s'il n'existe qu'une seule instance de TForm1 et que celle-ci est crée en affectant la variable Form1. C'est même le cas si la fiche est crée automatiquement dans le .DPR, mais c'es très mal de faire ça

la seule raison que je veux bien voir évoquer pour justifier de taper Form1, c'est pour avoir la complétion de code...mais c'est alors une erreur aussi, car il suffit d'utiliser Self !

Code :

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

1
2
3
4
5
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  Self.Caption := 'Hello';
end;

PS: EMC51 tu ne réponds pas à la question

PS2: l'usage des variables globales est un sujet récurant...

**peter27x** · 21/03/2013, 08h24

Envoyé par EMC51

Bonsoir,

Le .ini ça date un peu.

La base de registre ça sert aussi à cela.

Sinon, selon les cas, pourquoi ne pas utiliser un fichier XML ?...

Sauf que si l'utilisateur a un jour besoin de bosser sur un autre poste, il n'aura plus ses paramètres personnels. Tandis qu'avec le .ini, il peut " l'emporter " avec lui et garder ainsi son parametrage perso.

Les citations du genre "ça date un peu" je trouve que ça fait très "jeunisme" à outrance, sans forcément chercher à savoir ce qui est le plus pertinent, pratique et fonctionnel.

**SergioMaster** · 21/03/2013, 09h41

j'approuve le ini voire le XML , beaucoup moins la base de registre (quand on voit le b....l que c'est, autant s'en passer) .

J'utilise beaucoup la SGBD pour stocker les préférences perso dans le cas d'une application multi-users (avantage , le user n'a pas besoin " d'emporter avec lui " son fichier de préférences).

je pensais que l'on avait déjà répondu à tes introspections http://www.developpez.net/forums/d12...ace-variables/

**peter27x** · 21/03/2013, 10h23

Envoyé par SergioMaster

j'approuve le ini voire le XML , beaucoup moins la base de registre (quand on voit le b....l que c'est, autant s'en passer) .

J'utilise beaucoup la SGBD pour stocker les préférences perso dans le cas d'une application multi-users (avantage , le user n'a pas besoin " d'emporter avec lui " son fichier de préférences).

je pensais que l'on avait déjà répondu à tes introspections http://www.developpez.net/forums/d12...ace-variables/

Bien entendu, que le SGBD est mieux que le ini, mais rien ne laissait supposer ici que l'appli en question ait un accès SGBD, bien au contraire dirais je même.

**ShaiLeTroll** · 21/03/2013, 11h18

Pour répondre aux variables globales, il y a aussi une méthode pour les encapsuler !

Tu peux faire un record Contexte qui regroupe les paramétrages, tu peux subdiviser en sous record
record ou classe !

Il suffit de s'inspirer de TFormatSettings parfait exemple passage de globales à une approche plus "propre"

J'ai du développer assez rapidement une extension réutilisable pour compenser une fonctionnalité manquante dans le logiciel principal
L'intégration de cette fonctionnalité directement aurait été beaucoup plus longue avec trop d'impacts sur d'autres modules, j'ai donc fait un petit programme SANS DB, utilisant un ini pour la facilité de déploiement de modification via blocnote (les ini étant massivement utilisé dans le logiciel que je maintiens, trop je dirais même)

j'ai été confronté à ce même problème "des strings représentant des chemin d'accès."

Voici le prototype (j'ai juste changé les noms c'est le code réel)
Pour gérer les globales, j'ai juste un singleton qui contient ce qu'il faut pour les éléments de base utilisés dans le WinMain (le DPR en Delphi) et un peu partout dans le projet

Code c++ :

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
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
//---------------------------------------------------------------------------
//                        TPetitProjetEnvironnement                         -
//---------------------------------------------------------------------------
class TPetitProjetEnvironnement : public TObject
{
private:
  // Membres Privés (Singleton)
  static TPetitProjetEnvironnement *FSingletonInstance;
 
  // Membres Privés
  AnsiString FPathLogicielPrincipal;
  AnsiString FPathLogicielPrincipalIni;
  AnsiString FPathLogicielPrincipali18nIni;
  AnsiString FPathPetitProjetIni;
 
  HANDLE FMutexHandle;
  TUtilSociete *FUtilSociete;
  TIniFile* FPetitProjetIni;
 
private:
  // Constructeurs Protégés (Masqués)
  /*constructor*/__fastcall TPetitProjetEnvironnement();
 
public:
  // Constructeurs Publiques
  /*destructor*/virtual __fastcall ~TPetitProjetEnvironnement();
 
  // Méthodes Publiques (Singleton)
  static TPetitProjetEnvironnement* GetInstance();
  static TPetitProjetEnvironnement* Env() {return GetInstance();}
  static TPetitProjetEnvironnement* Ini() {return GetInstance();}
  static void ReleaseInstance();
 
  // Méthodes Publiques (Divers)
  static bool IsFirstInstance(TClass AWindowClass);
 
  // Méthodes Publiques (DLL)
  static bool ChargementDLLLogicielPrincipal();
  static bool DechargementDLLLogicielPrincipal();
 
  // Méthodes Publiques (Ini)
  AnsiString GetLogicielPrincipali18n(const AnsiString AIdent);
 
  // Propriétés Publiques
  __property AnsiString PathLogicielPrincipal = {read=FPathLogicielPrincipal};
  __property AnsiString PathLogicielPrincipalIni = {read=FPathLogicielPrincipalIni};
  __property AnsiString PathLogicielPrincipali18nIni = {read=FPathLogicielPrincipali18nIni};
  __property AnsiString PathPetitProjetIni = {read=FPathPetitProjetIni};
  __property TUtilSociete* UtilSociete= {read=FUtilSociete};
  __property TIniFile* PetitProjetIni = {read=FPetitProjetIni};
};
//---------------------------------------------------------------------------

et un des nombreux cas d’utilisation

Code c++ :

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

1
2
3
4
5
6
7
8
void TPetitProjetDeviceManager::LoadDeviceList()
{
  if (MainThreadID == GetCurrentThreadId())
  {
    TIniFile *ini = TPetitProjetEnvironnement::Ini()->PetitProjetIni;
    if (ini->SectionExists(DEVICE_SECTION_LIST))
    {
     ...

Code c++ :

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

1
2
3
4
5
6
7
bool TPetitProjetDeviceManager::InternalPollStart()
{
  int StartCount = 0;
 
  TPetitProjetEnvironnement::Env()->UtilSociete->Trace("StartPulser", "Lancement", true, true);
  FLogicielPrincipalEventPulser->StartPulser();
  ...

C'est juste une histoire syntaxe, au lieu d'avoir un tas de globale, tu as une seule globale qui encapsule un tas de propriété et de fonctionnalité générale !
Certains te diront que cela ressemble à une anti-pattern "Objet Divin" parce que c'est un fourre-tout sans cohérence !

Il faut juste que le code te plaise ET qu'il FONCTIONNE

**Andnotor** · 21/03/2013, 14h03

Envoyé par ShaiLeTroll

Pour répondre aux variables globales, il y a aussi une méthode pour les encapsuler !

C'est exactement ce que j'allais proposer avant de lire ton post

C'est à mon sens la meilleure solution, la plus souple et... celle que j'utilise.

Une seule méthode d'ouverture facilement adaptable (BdR, ini, xml, autres) et des propriétés encapsulées.
Un des gros avantages est de permettre la modification "à la volée" sans redémarrer l'application (surtout si c'est un serveur).
J'évite par contre le simple remplissage de variables. Même dans le cas d'un fichier, celui-ci est conservé en cache pour cause d'accès fréquents et ne souffre d'aucune latence

alternatives aux variables globales

Langage Delphi

Discussions similaires

Partager

Partager