Discussion :

[#define]

Bonjour à tous,

Ceci concerne à problème d'accès à des variables de classe.


L'application en construction possède :
- une ClasseA publique (mémorisation des paramètres globaux de l'application).
- une Form1 (affichage de l'application).
- une Form2 (définition des paramètres globaux de l'application) appelée depuis le menu de la Form1.

++++++++++++++++++
Etape 1:
Au démarrage, de l'application, la Form1 crée une instance de la classeA juste après "InitializeComponent()".
-> La Form1 lit sans problème les valeurs des variables de l'instance de la classeA.


++++++++++++++++++
Etape 2
Un menu de la Form1 ouvre la Form2.
Je souhaiterai que les valeurs définies dans la Form2 modifient les valeurs de l'instance active de la ClasseA créée par la Form1.



Dans le code de la Form2, il est impossible de faire référence à l'instance de la classeA de la Form1.
Comment puis-je coder cela ?

J'ai bien essayé avec une variable globale, mais le compilateur m'interdit le set/get à une variable globale.
Je tourne en rond sans trouver de solution.

Où est mon incompréhension ?

Merci par avance pour votre aide.

[Graffito]

On enchaine dans Form1:

Code :

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

1
2
3
4
MyClasseA = new ClasseA() ;
MyForm2 = new Form2() ;
MyForm2.Init(MyClasseA) ;
MyForm2.Show() ;  // ou ShowModal

et définir dans Form2 :

Code :

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

1
2
3
4
5
6
internal ClasseA  TheClasseA ;
...
internal void Init(ClasseA vTheClasseA) 
{
  TheClasseA=vTheClasseA ;
}

et dans les proc de Form2, utilise TheClasseA.

[#define]

Merci Graffito.

J'étudie cela.
Je n'ai jamais croisé ce type de code dans aucun de mes livres...
Meilleures amitiés.

[bacelar]

Avez-vous pensé au Design Pattern Singleton.
Ou encore plus simple, membre static d'une classe static.

Code :

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

1
2
3
4
public static class globauxToutSales
{
    public static int premiereGlobaleToutSales;
}

Je trouve cela très sale par rapport à un Singleton mais c'est bien mieux que de transférer de proche en proche des "variables"

[#define]

Bonjour Bacelar,

J'ai finalement opté pour variable et classe static avec un contrôle par get/set (comme indiqué au bas de mon premier post) ; une erreur de logique rendait mon code invalide auprès du compilateur...

Mais je vais étudier le code de Graffito parce que c'est une méthode que je ne connaissais pas et que je comprends pas encore tout à fait, en ce qui concerne la partie libellée "définir dans Form2 :".

Ma position "d'amateur débutant" y est certainement pour beaucoup...

Meilleures amitiés et encore merci pour tous.

[Miko95]

Bonjour,
Pour ton problème, si l'instance de la classe A se trouve dans le Form1, et que le Form2 est ouvert depuis le Form1, alors il faut que lors de l'ouverture du Form2 à l'aide de la méthode Show ou ShowDialog, tu spécifies le parametre owner en étant le Form1. Ensuite, depuis le Form2 tu peux accéder au Form1 et donc à l'instance de ta classe A. Biensur pour accéder à ton instance de la classe A, il faut qu'elle soit publique ou qu'il existe une propriété pour cette instance.

[Maniak]

Je trouve cela très sale par rapport à un Singleton

Des variables accessibles globalement via un singleton sont aussi des variables globales. C'est tout aussi 'sale' et c'est tout autant à éviter quand on peut faire autrement (ce qui est très souvent le cas).

mais c'est bien mieux que de transférer de proche en proche des "variables"

Mmh, communiquer aux classes les éléments dont elles ont besoin pour qu'elles puissent fonctionner indépendamment est toujours bien mieux que d'avoir du code qui repose sur des variables globales pour fonctionner.

Les cas dans lesquels un point d'accès extérieur est préférable sont très limités, et généralement en liaison avec des services. Ici, il n'est pas question de service, juste de transmettre à la création d'un objet un élément dont il a besoin pour fonctionner. C'est de faire du global pour ça qui est sale :)

Et donc, comme dit Miko95, il y a aussi la propriété Owner qui peut se caster, à condition de la renseigner explicitement.

[bacelar]

"Owner" est un mécanisme utilisé par le système de fenêtrage de Windows, il ne devrait pas être détourné pour des besoins d'implémentation de contexte global.
Les singletons est une méthode archaïque pour faire de l'inversion de dépendance. Maniak, en lisant le premier poste, vous verrez que l'on est dans un contexte de partages de configuration, donc une logique de container.
Utilisez une classe avec 15 paramètres dans don constructeur est plus compliqué à tester qu'une classe lié à un container.

[Miko95]

bacelar, tu veux dire qu'en général, pour accéder à un membre d'un form parent à partir d'un form enfant, on ne doit pas utiliser la propriété Owner?
Dans le cas ou le membre à acceder est static, ca va; mais dans l'autre cas, comment faire, est ce qu'il faut toujours garder une référence au membre nécessaire dans le form enfant(comme avec la méthode Init cité par Graffito ou en passant le membre au constructeur) ?

[bacelar]

Je ne vois pas de cas rationnel où une fenêtre fille devrait connaître sa fenêtre parent.
Dans le modèle Document/Vue ou Model/Vue/Controler, les enfants doivent connaître le document, et c'est tous.
Utilisez la méthode de Graffito, oui, mais pour passer le document, pas la fenêtre parent.

[SoaR245]

Je rejoins personnellement l'avis de Graffito dans le sens où chaque fenêtre doit être capable de fonctionner sans être forcement utilisée avec la form1. Pour permettre à la form2 d'être pouvoir utiliser correctement, il faut donc lui passer l'ensemble des informations nécessaires.

Créer un lien fort entre form2 et form1 risque de poser des problèmes le jour où une réutilisation externe de form2 voudra être faite.

[bacelar]

"L'ensemble des informations nécessaires", c'est le document de l'application.

[Maniak]

"Owner" est un mécanisme utilisé par le système de fenêtrage de Windows, il ne devrait pas être détourné pour des besoins d'implémentation de contexte global.
Maniak, en lisant le premier poste, vous verrez que l'on est dans un contexte de partages de configuration, donc une logique de container.

J'ai mal formulé ma réponse. Je voyais l'utilisation d'Owner comme une solution 'rapide' pour permettre d'accéder à classe1 via le mécanisme de communication enfant->parent que cette propriété représente, mais loin d'être la solution idéale. C'est pour ça que je ne l'ai mentionné que vite fait à la fin.

Mon post était à la base une réaction à la suggestion de passer par une classe statique. Pour ce qui est de la solution au problème initial, celle de Graffito allait très bien, si ce n'est que je passerais plutôt l'instance de classe1 directement dans le constructeur de Form2. Si Form2 en a besoin pour fonctionner, et vu qu'après le constructeur un objet est censé être en état de fonctionner, c'est à la fois plus logique et plus simple.

Là où j'ai un problème donc, c'est sur le principe de passer par des variables globales pour transmettre un bête objet.

Utilisez une classe avec 15 paramètres dans don constructeur est plus compliqué à tester qu'une classe lié à un container.

S'il y a besoin de passer 15 paramètres dans un constructeur, c'est qu'il manque une abstraction quelque part. Ici il n'était question que de passer l'instance de classe1 à Form2 pour qu'elle puisse faire son travail.

Entre passer explicitement _un_ objet regroupant les paramètres et en faire une variable globale (membres statiques d'une classe statique ou singleton), le premier est nettement plus propre que le deuxième.

Rien n'indique dans le post initial qu'il s'agit de transmettre ces informations dans 50 classes différentes à 50 niveaux différents. Il s'agit juste de les transmettre d'une classe à l'autre. Faire du global pour ça, c'est... laid :)


Au final, le post initial me fait juste penser à un manque de connaissances vis-à-vis du passage de références, mais rien de bien méchant. La solution de Graffito allait très bien pour indiquer qu'il suffit de passer l'instance de classe1 à Form2.

C'est la suggestion de passer par une classe statique (malheureusement celle qui a apparemment été retenue) qui m'a fait intervenir. Pour passer une donnée d'un objet à l'autre, non seulement ça n'a rien à voir avec de l'orienté objet, mais même en procédural ce serait considéré sale.


PS: sans rapport avec le problème initial, mais juste histoire de revenir sur l'utilisation de la propriété Owner : ok, ça crée un couplage entre l'enfant et le parent, donc à éviter si possible, mais les communications bidirectionnelles parent<->enfant ne sont pas forcément une abomination. Ça complique les choses, c'est clair, mais ça peut arriver quand même. Avec une forte préférence pour que ce soit limité à un groupe de classes qui fonctionnent toujours ensemble.

[#define]

Au final, le post initial me fait juste penser à un manque de connaissances vis-à-vis du passage de références.

Il est vrai que j'avais totalement oublié cette possibilité.
Je revois mon code.

Merci encore.