Discussion :

[mactwist69]

Bonjour la communauté.

Voilà, j'écris des classes pour des développeurs.
Je souhaitais enlever de l'intellisense les quelques fonctions qui ne sont pas utiliser par les développeurs, et rends l'utilisation des objets moins intuitifs...

Parmi eux : ToString, Equals (..) et GetHAshCode.

Pour les rendre invisible j'ai simplement fait :

Code :

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

1
2
3
4
<System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)>
Public Overloads Function GetHashCode() As Integer
      Return Nothing
End Function

Problème : Puisque GetHAshCode retourne tout le temps Nothing... On ne peut plus tester si l'objet contient Nothing (pour savoir si l'objet est chargé). Et j'aimerai bien garder cette fonctionnalité.

Question : Que doit on mettre dans cette méthode ? En cherchant sur internet, certains développeurs ont l'air de le réécrire à leur sauce, ce qui ne semble pas toujours propre. Idéalement, moi j'aimerai ne pas la toucher cette méthode, mais la rendre invisible. Quelqu'un aurait il une solution ou une méthode ?

[rv26t]

Bonjour mactwist69,

Et ainsi,

Code :

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

1
2
3
4
    <System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)>
    Public Overrides Function GetHashCode() As Integer
        Return MyBase.GetHashCode()
    End Function

Elle n'est plus visible avec l'intellisense, mais il est toujours possible de l'utiliser. (pas testé au travers d'une dll)
Ou alors j'ai loupé quelque chose dans la question.

[Sehnsucht]

Personnellement, je ne pige pas ; empêcher de voir des méthodes disponibles sur tout les objets juste parce que ... parce que je ne sais pas trop quoi d'ailleurs ; en quoi c'est moins intuitif ?
Par contre les développeurs qui veulent les utiliser eux risquent d'être gênés, ne les voyant pas ils n'auront pas forcément l'idée de les utiliser (alors qu'il suffit de les écrire "manuellement" pour y avoir accès mais encore faut-il le savoir)
Sans parler du fait que cet attribut n'est qu'une indication à l'éditeur qui n'est pas tenu de la respecter (par exemple le plugin Resharper lui s'en fiche et peut-être que SharpDevelop ou Xamarin studio font de même)

Bref tant de "travail" pour potentiellement si peu d'effets et l'obligation de modifier l'implémentation "classique" de la classe (parce qu'a priori s'il n'y avait pas le besoin de cacher ces méthodes elles ne seraient pas surchargées) je ne pige pas

[mactwist69]

Salut rv26t,

En fait en y regardant de plus prêts, c’était la fonctionnalité ToString qui m'intéressait.

En effet, lorsqu'un objet est instancié, et qu'on test si il est "Nothing" ça retourne Faux.
Si au contraire on assigne Nothing à l'objet, alors il retourne Vrai pour le même teste.

Ce que certains développeurs apprécient car on peut vérifier simplement l'instanciation.

Et il ne s'agissait donc pas de GetHashCode, mais de ToString.
Mais j'ai tout de même utilisé MyBase comme tu l'as indiqué, et ça marche très bien :

Code :

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

1
2
3
4
<System.ComponentModel.EditorBrowsable(System.ComponentModel.EditorBrowsableState.Never)>
Public Overloads Function ToString() As String
         Return MyBase.ToString
End Function

Bien que j'ai du mal à comprendre ce que me remonte MyBase sachant que ma classe ne dérive de rien...
Mais bon ça marche, je vais pas me plaindre.

Merci bien !

[tomlev]

En fait en y regardant de plus prêts, c’était la fonctionnalité ToString qui m'intéressait.

En effet, lorsqu'un objet est instancié, et qu'on test si il est "Nothing" ça retourne Faux.
Si au contraire on assigne Nothing à l'objet, alors il retourne Vrai pour le même teste.

Ce que certains développeurs apprécient car on peut vérifier simplement l'instanciation.

Je ne vois pas le rapport entre ToString et le fait de vérifier si une variable est nulle

Bien que j'ai du mal à comprendre ce que me remonte MyBase sachant que ma classe ne dérive de rien...

Si, elle dérive de Object, comme toutes les classes qui n'ont pas de classe de base explicite

[mactwist69]

Je ne vois pas le rapport entre ToString et le fait de vérifier si une variable est nulle

Code :

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

If MonObjet IS Nothing Then

Lorsque l'objet est instancié, le test renvoi False.
Quand l'objet n'est pas instancié, il renvoi True.

Lorsque ToString a été écrasé (pour envoyer toujours nothing), ce test renvoi toujours True, Il est là le rapport.

[tomlev]

Code :

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

If MonObjet IS Nothing Then

Lorsque l'objet est instancié, le test renvoi False.
Quand l'objet n'est pas instancié, il renvoi True.

Lorsque ToString a été écrasé (pour envoyer toujours nothing), ce test renvoi toujours True, Il est là le rapport.

Euh... non, le fait de redéfinir ou de masquer ToString ne change rien à ce test. Je te mets au défi de me prouver le contraire
Ca pourrait avoir un sens si tu faisais If MonObjet.ToString() Is Nothing, sauf que ça planterait quand MonObjet est Nothing

[DonQuiche]

Salut rv26t,

En fait en y regardant de plus prêts, c’était la fonctionnalité ToString qui m'intéressait.

En effet, lorsqu'un objet est instancié, et qu'on test si il est "Nothing" ça retourne Faux.
Si au contraire on assigne Nothing à l'objet, alors il retourne Vrai pour le même teste.

Ce que certains développeurs apprécient car on peut vérifier simplement l'instanciation.

Toi tu viens du php ou d'un langage de ce genre qui compare des chaînes à la structure de l'objet, non ?

En tout cas sache que nombre de développeurs C# considèreront ça comme un comportement exécrable, surprenant, qui va à l'encontre du langage et de ses conventions. Pour ma part je te conseille de travailler en C# avec les habitudes du C# et en php avec les habitudes du php.

Bien que j'ai du mal à comprendre ce que me remonte MyBase sachant que ma classe ne dérive de rien...

Si, toute classe et tout type valeur dérive de Object.

[mactwist69]

Toi tu viens du php ou d'un langage de ce genre qui compare des chaînes à la structure de l'objet, non ?

En tout cas sache que nombre de développeurs C# considèreront ça comme un comportement exécrable, surprenant, qui va à l'encontre du langage et de ses conventions. Pour ma part je te conseille de travailler en C# avec les habitudes du C# et en php avec les habitudes du php.

Ben raté, je ne fais que du VB que j'essai de faire en VB.

Ce n'est pas moi qui ait mis en place ces tests de Nothing sur la structure de l'objet.
Mais je poserai la question à celui qui à mis ça en place.

[Sehnsucht]

Bien que j'ai du mal à comprendre ce que me remonte MyBase sachant que ma classe ne dérive de rien...

Euh si ta classe dérive d'Object

En effet, lorsqu'un objet est instancié, et qu'on test si il est "Nothing" ça retourne Faux.
Si au contraire on assigne Nothing à l'objet, alors il retourne Vrai pour le même teste.

pas sûr d'avoir compris, pour tester la nullité d'une instance vous la comparez avec la chaine "Nothing" ; y'a mieux comme moyen

grillé par DonQuiche

[DonQuiche]

Puisque GetHAshCode retourne tout le temps Nothing... On ne peut plus tester si l'objet contient Nothing (pour savoir si l'objet est chargé). Et j'aimerai bien garder cette fonctionnalité.

Tu réalises qu'en modifiant ainsi le comportement de GetHashCode les dictionnaires et HashSet qui contiendraient ces objets rameraient comme ce n'est pas permis, ce qui sur un serveur serait une sacrée brèche pour une attaque DDOS ?

Les dictionnaires et HashSet reposent en effet sur GetHashCode avec pour hypothèse que statistiquement les hashes sont bien distribués. C'est ce qui fait que Dictionary.Get ou HashSet.Contains tournent en O(1) et non O(n): pour un hash donné il n'y a en moyenne qu'un élément à inspecter.

Question : Que doit on mettre dans cette méthode ? En cherchant sur internet, certains développeurs ont l'air de le réécrire à leur sauce, ce qui ne semble pas toujours propre. Idéalement, moi j'aimerai ne pas la toucher cette méthode, mais la rendre invisible. Quelqu'un aurait il une solution ou une méthode ?

Les hashes doivent être uniques (dans la mesure du possible), bien distribués et demeurer identiques même si tu changes les champs du type. Ce sont les contraintes que tu dois satisfaire et c'est loin d'être une question simple.

L'implémentation par défaut offre ces garanties pour les classes avec une valeur générée à la création de l'instance. En revanche pour les types valeurs l'implémentation mélange les champs, donc si tu en changes un le hash changera et selon les valeurs que peuvent prendre tes champs le résultat pourrait être mal distribué.

[tomlev]

DonQuiche résume bien le problème. Cette méthode n'est pas là pour faire joli, elle a une vraie utilité, et il ne faut pas l'implémenter n'importe comment, sinon on casse tout...

Si tu veux vraiment la cacher (ce que je trouve plus que discutable), prends plutôt la solution de rv26t.

[mactwist69]

Tu réalises qu'en modifiant ainsi le comportement de GetHashCode les dictionnaires et HashSet qui contiendraient ces objets rameraient comme ce n'est pas permis, ce qui sur un serveur serait une sacrée brèche pour une attaque DDOS ?

Et bien non, je ne réalisais pas.
C'est bien noté.