INDIRECTION SUR LES MEMBRES D'UNE CLASSE EN VB.NET OU C#, INDIRECTION ON CLASS M
oommeeggaa3d
Messages postés
97
Date d'inscription
dimanche 24 avril 2005
Statut
Membre
Dernière intervention
3 septembre 2010
-
19 oct. 2009 à 16:58
Whismeril Messages postés 19021 Date d'inscription mardi 11 mars 2003 Statut Contributeur Dernière intervention 16 avril 2024 - 23 avril 2018 à 16:55
Whismeril Messages postés 19021 Date d'inscription mardi 11 mars 2003 Statut Contributeur Dernière intervention 16 avril 2024 - 23 avril 2018 à 16:55
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/50710-indirection-sur-les-membres-d-une-classe-en-vb-net-ou-c-indirection-on-class-members-in-vb-net-or-c
https://codes-sources.commentcamarche.net/source/50710-indirection-sur-les-membres-d-une-classe-en-vb-net-ou-c-indirection-on-class-members-in-vb-net-or-c
Modifié le 23 avril 2018 à 16:57
Cependant l’usage des structures est déconseillé. La principale raison d'être est la compatibilité avec des dll codés dans un langage plus anciens.
Côté inconvénients
-C’est un type valeur, donc ça consomme de la mémoire inutilement à chaque passage en paramètres.
-Ça n’encapsule pas les variables.
-Y’a pas d’héritage.
-On ne peut pas faire de binding.
-Evidement, pas de méthode ni événement.
Bref c’est pas un objet, .Net est un langage objet. Utiliser une structure c’est aller à l’encotre du principe du lanage et du coup passer à côté de tous les points forts.
23 avril 2018 à 15:50
Tout d'abord merci pour tes explications cela va m'être fort utile.
Existe t'il par hasard le principe d'indirection concernant les membres d'une structure.
J'ai essayé de transposé ton code, mais les membres de ma structure ne sont pas affectés.
27 oct. 2009 à 09:51
Par contre, le dernier commentaire de hier soir de Charles Racaud, là, je comprends l'avantage maintenant, quand on a des membres non ordonnées. Il y en a peut-être d'autres...
26 oct. 2009 à 20:29
Je vois plutôt l'utilité ici pour récupéré des index non ordonnées. Juste des membre dont les index ne sont pas ordonnées (4, 6, 897, 7, 9876...) ou encore mettre un Id à la place d'un index. Mais la aussi, on peut remplacer par un Dictionary.
Il est vrai que utiliser la Reflection n'est pas trop conseiller ici si c'est pour utiliser dans un même projet. Mieux vaut utiliser les différents outils du framework, list, dictionary, ...
Source à utiliser pour de bonnes raisons.
__
Kenji
26 oct. 2009 à 17:46
26 oct. 2009 à 17:38
si je dois gérer des membres, si j'en ai 2, j'utiliserai membre1 et membre2, mais si j'en ai 150, je fais 1 tableau membres(150) as cequejeveux... d'ailleurs, j'ai toujours fait comme ca... depuis le gfa...
bref, je me pose 1 question tout simple : est-ce qu'il y a 1 avantage avec ta méthode par rapport à 1 simple tableau ?
26 oct. 2009 à 11:56
Public Function GetMembre(Of T)(ByVal Index As Integer) As T
Dim oType As Type = MyClass.GetType
Dim FI As FieldInfo = oType.GetField("Membre" & Index.ToString)
If Type.Equals(FI.FieldType, GetType(T)) Then
Return CType(FI.GetValue(Me), T)
Else
Throw New InvalidCastException(String.Format("Unable to cast object of type '{0}' to type '{1}'", FI.FieldType, GetType(T)))
End If
End Function
Public Sub SetMembre(Of T)(ByVal Index As Integer, ByVal Value As T)
Dim oType As Type = Me.GetType
Dim FI As FieldInfo = oType.GetField("Membre" & Index.ToString)
If Type.Equals(FI.FieldType, GetType(T)) Then
FI.SetValue(Me, Value)
Else
Throw New InvalidCastException(String.Format("Unable to cast object of type '{0}' to type '{1}'", GetType(T), FI.FieldType))
End If
End Sub
21 oct. 2009 à 11:27
21 oct. 2009 à 09:13
Forme normale (bases de données relationnelles)
http://fr.wikipedia.org/wiki/Forme_normale_(bases_de_donn%C3%A9es_relationnelles)
21 oct. 2009 à 08:49
Mais en dehors de toutes contraintes de performance mon seul soucis est d'avoir le code le plus simple et lisible possible. Ce genre de code me va donc très bien.
PS : Level1 à Level5, il s'agit d'un logiciel de GED et chaque table gère un niveau. En factorisant certains champs, je créé de nouvelles tables? Or, toujours dans un soucis de praticité je code une classe de pilotage par table dans ma BDD. Donc plus de tables => plus de classes.
21 oct. 2009 à 08:37
20 oct. 2009 à 17:50
Exemple, je suis en train de developper un logiciel de BDD avec les tables suivantes LEVEL1, LEVEL2... LEVEL5. Les tables possèdent des champs identiques et des champs différents. J'ai donc codé une classe pour chacune d'elle (cLevel1... cLevel5). Pas de tableau possible car les objets sont de type différent. Pour savoir à quelle classe accéder, je dois à chaque dois utiliser un Select Case 'Integer'. Ce genre de code me permettrait de m'en passer.
20 oct. 2009 à 16:19
20 oct. 2009 à 11:03
Public Property Membre(ByVal Index As Integer) As Integer
Get
Dim oType As Type = Me.GetType
Dim FI As FieldInfo = oType.GetField("Membre" & Index.ToString)
Return FI.GetValue(Me)
End Get
Set(ByVal value As Integer)
Dim oType As Type = Me.GetType
Dim FI As FieldInfo = oType.GetField("Membre" & Index.ToString)
FI.SetValue(Me, value)
End Set
End Property
On utilise ensuite :
Membre(i) = 10
MsgBox Membre(i)
19 oct. 2009 à 16:58