Discussion :

[Nicorombe]

Bonjour,

J'aurais souhaité savoir si il y avait un danger à liées deux classes entres elles par double affectation.

Voici un exemple pour illustrer ma question : J'ai deux classes, Propriétaire et Voiture, pour les quelles à chaque Propriétaire correspond une unique Voiture, et pour chaque Voiture un unique Propriétaire. Puis-je lier mes classes Propriétaire et Voiture de la manière suivante

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
28
29
30
31
32
33
 
Class Propriétaire
    Public Nom as String
    Public Voiture as Voiture
 
    Public Sub New(m_Nom as String)
        Nom = m_Nom
        Voiture = New Voiture(Me)
        ListeVoiture.Add(Voiture)
    End Sub
 
End Class
 
Class Voiture
    Public Marque as String
    Public Couleur as Color
    Public Propriétaire as Propriétaire
 
    Public Sub New(m_Propriétaire as Propriétaire)
        Propriétaire = m_Propriétaire
    End Sub
 
End Class
 
Public Sub Main()
 
    Dim ListeVoitures as New List(of Voiture)
    Dim Propriétaire1 as New Propriétaire("Toto")
 
    'Récupération du nom du propriétaire de la première voiture de la liste
    Msgbox(ListeVoitures(0).Propriétaire.Nom)
 
End Sub

Le but de la manœuvre est de pouvoir accéder aux propriétés du Propriétaire depuis l'objet Voiture. Est-ce une bonne solution ou y-a-t-il une solution plus élégante ?

Merci pour votre aide !

Nicolas.

[Geo2A]

Bonjour,

Votre code révèle quelques confusions en matière d'approche objet.

une unique Voiture

Alors pourquoi une liste de voiture pour la classe propriétaire ?

Deuxièmement il est bon d'accéder aux propriétés d'une classe via les accesseurs Get et Set et d'utiliser à l'intérieur de la classe une variable interne.
Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
Public Class Classproprietaire
 
    Private mNom As String
    Public Property Nom() As String
        Get
            Return mNom
        End Get
        Set(ByVal value As String)
            mNom = value
        End Set
    End Property
 
End Class

Ensuite dans la procédure New de propriétaire

Code :

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

Voiture = New Voiture(Me)

Ne va pas marcher, car il faut instancier avec le nom donc

Code :

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

Voiture = New Voiture(Me.nom)

[ctxnop]

Salut,

J'aurais souhaité savoir si il y avait un danger à liées deux classes entres elles par double affectation.

Le danger de ca c'est qu'il s'agit d'une référence circulaire, un objet A référence un object B qui lui même référence l'objet A, etc...
Résultat, si ton code ne découple pas les deux à un moment ou à un autre, aucun de ces deux objets ne sera détruit, le garbage collector verra qu'ils sont tout deux référencés.

[Bluedeep]

Le danger de ca c'est qu'il s'agit d'une référence circulaire, un objet A référence un object B qui lui même référence l'objet A, etc...
Résultat, si ton code ne découple pas les deux à un moment ou à un autre, aucun de ces deux objets ne sera détruit, le garbage collector verra qu'ils sont tout deux référencés.

A cela il convient d'ajouter les problèmes de sérialisation avec des objets en références circulaires.

[Geo2A]

Bonjour,

A cela il convient d'ajouter les problèmes de sérialisation avec des objets en références circulaires.

Parfaitement d'accord avec vous mais il m'avait semblé qu'il fallait commencer par le début avant d'attaquer des problématiques plus complexes.

[ctxnop]

Moi il me semble qu'il est bien plus complexe de prendre en compte ce genre de chose a priori plutôt qu'a postériori. Revenir sur ce genre de chose peut demander un travail gigantesque en refactoring et même en recherche des occurrences de ces problèmes.

[Bluedeep]

Moi il me semble qu'il est bien plus complexe de prendre en compte ce genre de chose a priori plutôt qu'a postériori.

Tu veux dire le contraire je suppose ?

En effet :

Revenir sur ce genre de chose peut demander un travail gigantesque en refactoring et même en recherche des occurrences de ces problèmes.

[Kropernic]

Et donc, pour en revenir à la question de base (car elle m'intéresse également), comment fait-il pour savoir qui est le propriétaire de la voiture ?

[ctxnop]

Et donc, pour en revenir à la question de base (car elle m'intéresse également), comment fait-il pour savoir qui est le propriétaire de la voiture ?

Et bien le plus "simple" a mon sens c'est que la classe Propriétaire embarque une valeur identifiant l'instance de manière unique (par exemple le nom du propriétaire si on peut considérer cette variable comme unique, ou carrément un identifiant supplémentaire du genre Guid).
Ainsi, Voiture ne référence pas un objet Proprietaire, mais plutôt la valeur identifiant le propriétaire.
Cette façon de faire permet de découpler les deux classes tout en gardant un moyen de retrouver le propriétaire.
Par contre, elle impose recherche du propriétaire, plutôt qu'accès directe.

[ctxnop]

Ce que je voulais souligner c'est qu'avant d'aborder des notions complexes comme les références circulaires il faut déjà maîtriser la base en matière de POO.
quand je lis m_Nom en paramètre d'une procédure New je me fais un peu de soucis. Mais bien évidement il vaut mieux avant de se lancer dans un programme complexe maîtriser l'ensemble des concepts. Ceci dit on a tous commencer par "Hello World".

Plutot d'accord, cependant sa question c'était

Bonjour,

J'aurais souhaité savoir si il y avait un danger à liées deux classes entres elles par double affectation.

Bah on a répondu à la question : le danger c'est que c'est une référence circulaire. Et on a donner deux exemples des effets pervers des références circulaires.

[Bluedeep]

Bah on a répondu à la question : le danger c'est que c'est une référence circulaire. Et on a donner deux exemples des effets pervers des références circulaires.

On peut au demeurant (un peu) limiter l'impact via les WeakReference, mais on sort un peu du cadre de la programmation "débutant"

[Nicorombe]

Merci à tous pour vos réponses.
Il me semble effectivement que la solution la plus simple (et la moins dangereuse) soit d'ajouter une propriété Keyprop à chaque voiture qui identifie de manière unique le propriétaire.

Par ailleurs, comme le signalait Geo2A :

Deuxièmement il est bon d'accéder aux propriétés d'une classe via les accesseurs Get et Set et d'utiliser à l'intérieur de la classe une variable interne.

Y-a-t-il une véritable différence à utiliser les structures Property pour accéder aux propriétés d'une classe plutôt que de les déclarer Public, ou s'agit-il plus d'une convention de programmation ?

Merci.

[ctxnop]

On va dire que c'est une convention, mais qu'il vaut mieux la respecter.
Le fait est qu'une property n'est pas une variable locale mais un jeu de deux méthodes (ou juste une seule, selon comment elle est déclarée).
Cela signifie que tu peux ajouter du code dessus.
Par exemple, sur un Set tu peux vérifier que la valeur est valide et lancer une exception si ca n'est pas le cas, chose que tu ne peux pas faire si on accède directement a la valeur.
Tu peux également, sur le Get d'une propriété, t'assurer que l'instance existe et la créer si ce n'est pas le cas, ainsi, de l'extérieur, la propriété ne vaut jamais null.

Et sinon, mais la on rentre dans un truc un peu plus complexe : la plupart des mécanisme de sérialisation, de binding, etc... fonctionnent via la reflection en obtenant la liste des propriétés de l'objet. Si tu met les membres en public pour ne pas avoir a déclarer de propriété, ils ne seront pas visibles à ces mécanismes, en conséquences tu ne pourra pas sérialiser tes objets (enfin si, y'a toujours moyen, mais tu va galérer alors que ca se fait tout seul si tu respecte la convention)

[Geo2A]

Bonjour,

Y-a-t-il une véritable différence à utiliser les structures Property pour accéder aux propriétés d'une classe plutôt que de les déclarer Public

Oui et elle n'est pas mince. C'est un concept essentiel de la programmation objet: l'encapsulation.

En déclarant une variable Public au niveau d'une classe, n'importe quelle ligne de code à l'intérieur du programme pourra venir modifier cette variable.

En utilisant les accesseur on déclare une variable membre à l'intérieur de la classe (mNom dans mon exemple) que l'on préfixe par habitude par m ou m_ (membre de). C'est cette variable qui sera utilisée à l'intérieur de la classe, qui sera ENCAPSULEE dans la classe, et seule les méthodes de la classe pourront l'affecter car la variable a pour portée la classe qui la contient. Elle sera invisible au autres objets du programme. La seule façon alors d'affecter la variable memebre depuis l'extérieur de la classe sera de faire un appel explicite à la propriété via l'accesseur set en écrivant:
monobjet.Nom= machin et d'un point de vue interne à la classe cela déclenchera mNom=machin

Est-ce clair ?

[Nicorombe]

Merci, je comprends bien la différence maintenant.

Et sinon, mais la on rentre dans un truc un peu plus complexe : la plupart des mécanisme de sérialisation, de binding, etc... fonctionnent via la reflection en obtenant la liste des propriétés de l'objet. Si tu met les membres en public pour ne pas avoir a déclarer de propriété, ils ne seront pas visibles à ces mécanismes, en conséquences tu ne pourra pas sérialiser tes objets (enfin si, y'a toujours moyen, mais tu va galérer alors que ca se fait tout seul si tu respecte la convention)

Puisqu'on aborde ces mécanismes, j'en profite : je me sers effectivement de la reflection pour lister les propriétés de mes classes. Puisque toutes mes propriétés étaient déclarées en Public, j'utilisais jusque là quelque chose du type :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
myType = MonObjet.GetType()
Try
    Dim myFields As FieldInfo() = myType.GetFields()
    For i As Integer = 0 To myFields.Length - 1
        Dim row As String() = {myFields(i).Name, myFields(i).GetValue(MonObjet)}
        DataGridView1.Rows.Add(row)
    Next i
Catch ex As Exception
    Dim row As String() = {"Erreur", ""}
    DataGridView1.Rows.Add(row)
End Try

Si j'utilise maintenant des propriétés, la méthode GetValue() des PropertyInfo nécessite un argument supplémentaire index(). A quoi correspond-il ?

Merci.