Discussion :

[zax-tfh]

Bonjour à tous,

Je me pose une question existencielle :
Imaginons deux classes :
Classe1
Classe2

Classe1 manage une collection d'objets de type Classe2
Classe2 possède une propriété ou un attribut, peut importe, que l'on nommera Attr1

J'aimerai que Classe1 ait accès à Classe2.Attr1 sans pour autant qu'il soit visible à tous le reste de l'appli.
En gros, je voudrais donner le droit d'accès à cette propriété uniquement à Classe1
Si dans mon appli je créé un objet de type Classe2, je ne dois pas pouvoir setter la property.

Savez vous comment on peut réaliser une telle chose ?

Contrainte : Classe1 et Classe2 sont deux classes bien distinctes, dans deux fichiers différents, et on doit quand meme pouvoir créer et utiliser un objet de type Classe2 de l'exterieur (c'est juste que certaines propriétés sont masquées quoi), donc la solution de créer une classe Classe2 en private à l'interieur de Classe1 est exclue.

Merci d'avance
@ bientot

[Kyaan]

Je vais essayer de ne pas dire de bétise mais si j'ai bien compris ton problème, tu peux faire hériter ta Classe1 de la Classe2 et tu met Attr1 en protected, seul la Classe1 pourra y accéder...

[zax-tfh]

Merci de ta réponse. Alors, ce que tu dis est juste à partir du moment où tu trouves un interet de faire heriter Classe1 de Classe2. A ce moment là, la property Classe2.Attr1 mise en protected sera effectivement visible uniquement par Classe1.

Sauf que là c'est bel et bien deux classes distinctes donc pas d'heritage

[Bluedeep]

Merci de ta réponse. Alors, ce que tu dis est juste à partir du moment où tu trouves un interet de faire heriter Classe1 de Classe2. A ce moment là, la property Classe2.Attr1 mise en protected sera effectivement visible uniquement par Classe1.

Sauf que là c'est bel et bien deux classes distinctes donc pas d'heritage

Isole tes deux classes dans une assembly, et mets cette propriété en internal.

[zax-tfh]

Pourrais tu etre plus précis stp ? je ne connais pas ce "internal"
Merci

[Bluedeep]

Un membre déclaré internal est public dans son assembly et private pour l'extérieur. (donc non visible de l'extérieur).

[Keihilin]

internal est un type de portée (au même titre que private, public et protected).

Cela donne la visibilité sur un membre d'une classe aux objets faisant partie de la même assembly.

[zax-tfh]

Je ne le connaissais pas celui là !!!!
Merci à tous !

Pour la peine, je tagge résolu

[zax-tfh]

Je comprend mieux pourquoi je ne le connaissais pas ^^
C'est du C#, or je code en VB
Donc en Vb c'est Friend (Je le connaissais mais c'est vrai que je l'utilise pas souvent, voire pas du tout...donc un peu passé aux oubliettes...)

[Bluedeep]

Je comprend mieux pourquoi je ne le connaissais pas ^^
C'est du C#, or je code en VB

Ah en effet, mais comme tu le dis, tu ne l'avais pas précisé, donc on pensait

[mode troll on]
que tu codais avec un "vrai" langage
[mode troll off]

[zax-tfh]

Lol ça pue le troll grave
Sans vouloir relever le débat ni commencer un troll (par pitié je veux juste dire un ptit truc après si vous voulez troller, faites le en PM, qu'on se fasse pas squizzer le topic).
Je rencontre pas mal de professionnels qui confirment qu'ajourd'hui la différence Vb / C# est plus que mince : L'un dans l'autre, le CLR est le meme...

A vous les studios !

[Bluedeep]

Je rencontre pas mal de professionnels qui confirment qu'ajourd'hui la différence Vb / C# est plus que mince : L'un dans l'autre, le CLR est le meme...

C'est absolument exact.

De plus tu peux coder exactement la même chose dans les deux langages, et il est virtuellement impossible de distinguer en examinant l'IL généré quel langage a été utilisé. (sauf si tu utilises les vieilles verrues de compatibilité avec VB6, - CDate et autres - mais, là cela relève de la mauvaise pratique et rien d'autre ).

Non, simplement je n'aime pas les syntaxes VB. C'est purement subjectif. Quand je suis passé à .Net (avant j'utilisais le couple VB6/C++ pour les applis Windows : VB6 pour l'IHM de l'appli, C++ pour tout le reste), le choix a été vite fait : C# et basta.

[Keihilin]

et il est virtuellement impossible de distinguer en examinant l'IL généré quel langage a été utilisé.

Inexacte.

Je n'ai pas vérifié sous 3.5, mais en 1.1 et 2.0 les compilateurs C# et VB.Net ne produisaient pas exactement le même code IL. Les chances de trouver des différences dans un programme conséquent (je ne parle pas d'un hello world) sont proche de 100%.

Cela dit, moi non plus je n'aime pas la syntaxe lourde et verbeuse de VB.Net, mais au-delà de ça, si vous observez l'évolution depuis 2002, il y a de moins en moins d'adèptes de VB (ça fait une éternité que j'ai pas vu un article en VB sur codeproject).

Si aujourd'hui Microsoft devait abandonner un langage, je parierai que c'est VB qui passerait à la trappe, pas C#.

[Bluedeep]

Inexacte.

Je n'ai pas vérifié sous 3.5, mais en 1.1 et 2.0 les compilateurs C# et VB.Net ne produisaient pas exactement le même code IL.

Pas besoin de vérifier en 3.5, puisque le compilateur (du moins la partie génération de l'IL) est quasiement identique entre 2.0 et 3.5; en effet, les extensions du C# 3.0 (vs le 2.0) sont juste "pré-processées". Donc ton affirmation reste valide.

Peux tu me dire quels sont les différences qui permettent de connaitre la provenance du code source ? (ceci dit, je me suis peut être mal exprimé : je n'ai pas voulu dire que sur des lignes de codes semblables, C# et VB donnent le même code, mais seulement qu'il n'est pas possible en lisant un IL de connaitre sa provenance a priori - sauf à connaitre certaines "astuces " de traduction IL propre à un langage ou l'autre).

[Keihilin]

Ben en fait la différence la plus évidente réside dans le code généré pour une fonction (donc une méthode ne retournant pas void).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
public class IL
{
    public int foo(bool test)
    {
        int i;
        i = (test) ? 1 : 2;
        return i;
    }
 
}

Code :

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

1
2
3
4
5
6
7
8
9
10
 
Public Class IL
 
    Public Function foo(ByVal test As Boolean) As Integer
        Dim i As Integer
        i = (test) ? 1 : 2
        Return i
    End Function
 
End Class

Génère le code IL suivant pour C# :

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
 
.method public hidebysig instance int32  foo(bool test) cil managed
{
  .maxstack  1
  .locals init (int32 V_0)
  IL_0000:  ldarg.1
  IL_0001:  brfalse.s  IL_0007
  IL_0003:  ldc.i4.1
  IL_0004:  stloc.0
  IL_0005:  br.s       IL_0009
  IL_0007:  ldc.i4.2
  IL_0008:  stloc.0
  IL_0009:  ldloc.0
  IL_000a:  ret
} // end

et pour VB :

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
.method public instance int32  foo(bool test) cil managed
{
  .maxstack  1
  .locals init (int32 V_0, int32 V_1)
  IL_0000:  ldarg.1
  IL_0001:  brfalse.s  IL_0007
  IL_0003:  ldc.i4.1
  IL_0004:  stloc.1
  IL_0005:  br.s       IL_0009
  IL_0007:  ldc.i4.2
  IL_0008:  stloc.1
  IL_0009:  ldloc.1
  IL_000a:  ret
} // end

Cette variable surnuméraire V_1 est présente en VB car ce dernier, plus permissif, permet à une fonction de ne pas avoir de valeur de retour explicitement déclarée. Cette fameuse variable est utilisée dans ces cas-là...

Ca n'a pas toujours d'impact significatif, mais les philosophies différentes de C# et VB.net donnent de l'IL différent...