Discussion :

[rozwel]

Développeur Java pure souche à la base, je suis en train de découvrir C# à travers le document de Serge Tahé et j'en suis à la section sur la redéfinition des opérateurs. Le problème c'est que j'ai beaucoup de mal à comprendre la logique qui veut que les redéfinitions d'opérateurs soient déclarés statiques, avec comme premier paramètre une instance de la classe ou est redéfini l'opérateur. Est-ce que quelqu'un pourrait m'expliquer pourquoi les concepteurs du langage n'ont pas préféré une approche plus orientée objet qui aurait consisté à déclarer les redéfinitions d'opérateurs comme de simples méthodes d'instances ?

[davcha]

En quoi aurait-ce été une approche davantage orientée objet ?

[jab]

Une methode static sur une classe, ce n'est jamais qu'une fonction. Il n'y a rien d'objet la dedans.

[Invité]

Je trouve au contraire que les méthodes static sont justement les fonctions classiques dans le concept objet. Si techniquement ce n'est rien de plus qu'une fonction, ça a une signification bien précise, en tout cas pour moi, et je les utilise bien sûr différement des fonctions.

Une fonction est membre d'une classe, ce n'est pas rien, il y a une notion de portée (la méthode static peut accéder aux membres privés, mais vous allez sans doute me sortir le mot-clef friend).

[davcha]

Pas d'accord avec jab. C'est une fonction dans un espace de nom.
D'un point de vue sémantique, la fonction statique a un lien fort avec la classe.
D'un point de vue technique, pour y accéder, il faut préciser la classe. Il y a donc une partition en espace de nom, qui est importante en objet.

[Maniak]

Une methode static sur une classe, ce n'est jamais qu'une fonction. Il n'y a rien d'objet la dedans.

Une méthode statique appartient à une classe. Une classe est un objet comme un autre. Il n'y a rien de non-OO là-dedans.

Une méthode *globale* en revanche, là oui, ça n'a rien d'OO. Mais la seule façon de reproduire ça en .NET c'est avec un singleton (à consommer avec très grande modération donc), et les méthodes statiques ne sont pas limitées aux singletons (heureusement).

Les opérateurs sont très bien au niveau des classes. Ils n'appartiennent pas à une instance donnée.

[NicolasG]

JUne fonction est membre d'une classe, ce n'est pas rien, il y a une notion de portée (la méthode static peut accéder aux membres privés, mais vous allez sans doute me sortir le mot-clef friend).

Accéder aux membre privés static uniquement.
Sinon, il faut bien une instance de cette classe.
...

Une méthode *globale* en revanche, là oui, ça n'a rien d'OO. Mais la seule façon de reproduire ça en .NET c'est avec un singleton (à consommer avec très grande modération donc), et les méthodes statiques ne sont pas limitées aux singletons (heureusement).

Je ne vois pas le rapport entre méthode globale et singleton.
Un singleton permet d'avoir une instance unique. Ce n'est pas utile pour accéder à une méthode static.

[jab]

Je ne voulai pas dire que ce n'est pas OO et que ce n'est pas pratique, j'en utilise aussi souvent. C'est très utilisé par exemple en orienté service mais le concept OO de base c'est j'ai un objet et j'applique une action dessus. Avec une méthode static c'est un peu différent. Les propriétés que l'on accède doivent aussi être Static.
Mais on ne va pas en débattre toute la nuit surtout par forum se serait trop fastidieux.

[rozwel]

Surtout que la question de depart n'etait pas tant de savoir si static c'est objet ou pas que d'essayer de comprendre pourquoi on billou a decide de nous obliger a redefinir les operateurs avec une methode static alors que, dans ce cas precis, une methods d'instance nous aurait permis de nous passer de ce premier parametre redondant qui correspond en fait a la premier operande.

Personnellement, cela m'aurait paru beaucoup plus intuitif que objet1+objet2 soit equivalent a objet1.operator+(objet2) plutot qu'a objet1.GetType().operator+(objet1,objet2), non ? (si tant est que ce soit bien GetType() la methode pour recuperer la classe d'une instance, je ne sais plus)

[davcha]

En même temps, si tu redéfinis les opérateurs, c'est pas pour faire object1.GetType().operator+(object1,object2), hein...

Et .NET non plus ne fait pas ça. Quand tu compiles ton programme, le compilo sait quel est le type des objets mis en oeuvre dans les instructions faisant appels aux opérateurs.

Y'a pas de différence entre le style Java ou c# à ce niveau là.

[NicolasG]

Surtout que la question de depart n'etait pas tant de savoir si static c'est objet ou pas que d'essayer de comprendre pourquoi on billou a decide de nous obliger a redefinir les operateurs avec une methode static alors que, dans ce cas precis, une methods d'instance nous aurait permis de nous passer de ce premier parametre redondant qui correspond en fait a la premier operande.

Et si on fait nullptr + objet1, on appelle une méthode de l'objet nullptr évidemment.

[Maniak]

mais le concept OO de base c'est j'ai un objet et j'applique une action dessus. Avec une méthode static c'est un peu différent. Les propriétés que l'on accède doivent aussi être Static.

En jetant un coup d'oeil du côté de SmallTalk, la différence est assez vite gommée :
Les membres non-statiques appartiennent à une instance d'une classe.
Les membres statiques appartiennent à une instance d'une metaclasse.

Les instances des classes sont les objets qu'on utilise habituellement.
Les instances des metaclasses sont les classes elles-mêmes.

C'est le niveau supérieur, mais le fonctionnement reste le même :)

Je ne vois pas le rapport entre méthode globale et singleton.

Les singletons sont utilisés pour reproduire (grosso modo) une variable globale. Variable globale qui peut donc avoir des méthodes, qui se trouvent donc être des méthodes globales :)

Pour rejoindre ce qui est dit plus haut :
Les méthodes d'un singleton sont les méthodes d'une instance (de classe) unique.
Les méthodes statiques sont les méthodes d'une instance (de metaclasse) unique.

La manière d'obtenir l'instance unique varie (de peu, un singleton utilise fatalement du statique quelque part :), mais le résultat est le même.

[rozwel]

En même temps, si tu redéfinis les opérateurs, c'est pas pour faire object1.GetType().operator+(object1,object2), hein...

Et .NET non plus ne fait pas ça. Quand tu compiles ton programme, le compilo sait quel est le type des objets mis en oeuvre dans les instructions faisant appels aux opérateurs.

Y'a pas de différence entre le style Java ou c# à ce niveau là.

En fait je pensais plus à la façon dont le CLR interprétait un opérateur, et même avec ta précision, je ne vois toujours pas l'intérêt de remonter d'un niveau jusqu'à la classe alors qu'on pourrait avoir la première opérande sous la main. Mais enfin bon. Là où ça pose une question chiante, c'est de savoir ce qui m'empêche de déclarer comme premier paramètre une classe qui n'a rien à voir avec celle dans laquelle l'opérateur est défini. Par exemple:

Code :

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

1
2
3
4
 
public class Truc{
  public static Truc operator+(string s1, string s2){...}
}

Qu'est-ce qui nous empêche d'écrire ça? Et si rien ne nous en empêche, comment le compilateur identifie-t-il ce qu'il doit faire sur "bi"+"dule"? Question vraiment innocente.

[NicolasG]

La manière d'obtenir l'instance unique varie (de peu, un singleton utilise fatalement du statique quelque part , mais le résultat est le même.

Le résultat est bien similaire mais je me demande comment tu peux préférer écrire MaClasse.GetInstance().MaMethode() plutôt que MaClasse.MaMethode()
Sans parler du codage de GetInstance()...

Je n'ai encore jamais eu besoin de singleton en utilisant à la place les membres static.

[davcha]

Code :

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

1
2
3
4
 
public class Truc{
  public static Truc operator+(string s1, string s2){...}
}

Qu'est-ce qui nous empêche d'écrire ça? Et si rien ne nous en empêche, comment le compilateur identifie-t-il ce qu'il doit faire sur "bi"+"dule"? Question vraiment innocente.

Oui, mais non. Tu n'as pas le droit d'écrire ça. L'un des deux paramètres doit être du type Truc.

Le résultat est bien similaire mais je me demande comment tu peux préférer écrire MaClasse.GetInstance().MaMethode() plutôt que MaClasse.MaMethode()
Sans parler du codage de GetInstance()...

Je n'ai encore jamais eu besoin de singleton en utilisant à la place les membres static.

Tu contrôles mieux ce que tu fais avec un singleton... Enfin bon... Disons que c'est plus "évident".

[Maniak]

Le résultat est bien similaire mais je me demande comment tu peux préférer écrire MaClasse.GetInstance().MaMethode() plutôt que MaClasse.MaMethode()

Plutôt simplement .Instance ou .Current pour suivre ce qui se retrouve le plus souvent dans le framework. Et pour peu que ce soit utilisé plusieurs fois de suite, ça passe dans une variable locale, donc tout aussi simple à écrire :)
(et on n'est pas à 3 touches près de toute façon)

Sans parler du codage de GetInstance()...

http://www.yoda.arachsys.com/csharp/singleton.html
La 4è version est très bien, et le code est on ne peut plus bref :)

Je n'ai encore jamais eu besoin de singleton en utilisant à la place les membres static. :D

- en ASP.NET, à moins de faire un singleton qui est stocké en fait dans HttpContext.Current.Items, l'instance est partagée entre toutes les requêtes exécutées sur le serveur. Pas glop dans de nombreux cas
- pas de polymorphisme avec les méthodes statiques
- pas de moyen de remplacer l'instance par une version 'light' pour les tests

[rozwel]

Le résultat est bien similaire mais je me demande comment tu peux préférer écrire MaClasse.GetInstance().MaMethode() plutôt que MaClasse.MaMethode()
Sans parler du codage de GetInstance()...

Je n'ai encore jamais eu besoin de singleton en utilisant à la place les membres static.

Mais je n'ai jamais voulu avoir une GetInstance() justement c'est tout le contraire. Quand tu appliques un opérateur, tu l'appliques sur des instances non ? Donc l'opérande de gauche est déjà disponible, pas besoin de remonter au niveau de la classe pour récupérer une méthode statique de surcharge d'opérateur.

Enfin bref apparemment on ne s'en sort pas, j'ai l'impression que c'est vraiment une question de perception. Moi ça me parait maladroit mais ça parait surement beaucoup plus naturel à ceux qui ont beaucoup travaillé avec des langages procéduraux (partiellement procéduraux comme C++) de considérer les surcharges d'opérateurs comme des méthodes de type librairie.

[NicolasG]

rozwel

Mais je n'ai jamais voulu avoir une GetInstance() justement c'est tout le contraire.

Pas de panique, c'était une considération sur les singletons. Ca n'a rien à voir avec les surcharges d'opérateurs.

Maniak

- en ASP.NET, à moins de faire un singleton qui est stocké en fait dans HttpContext.Current.Items, l'instance est partagée entre toutes les requêtes exécutées sur le serveur. Pas glop dans de nombreux cas

Ok, si on a besoin de passer une instance unique à plusieurs objets, le singleton s'impose.

- pas de polymorphisme avec les méthodes statiques

Désolé, c'est faux. Je l'ai vérifié en C# et en C++/CLI.

- pas de moyen de remplacer l'instance par une version 'light' pour les tests

Là, je ne vois pas la différence.

[Maniak]

Quand tu appliques un opérateur, tu l'appliques sur des instances non ?

Tu réponds à ta propre question :)

Un opérateur s'applique *sur* *des* instances.
Ce n'est pas une opération effectuée *par* une instance, sur une autre.

Quand tu appliques l'opérateur +, tu l'appliques sur deux instances, et tu en obtiens une troisième. L'opération n'appartient pas à une des deux premières instances.

Donc l'opérande de gauche est déjà disponible, pas besoin de remonter au niveau de la classe pour récupérer une méthode statique de surcharge d'opérateur.

Faut savoir si tu veux gagner quelques caractères au niveau de la syntaxe, ou avoir un fonctionnement sémantiquement correct, correctement orienté objet et qui fonctionne correctement :)


Allez, encore un exemple.
Si l'opérateur + était affecté à une instance, ça reviendrait à une méthode Add.
Si tu fais 'toto.Add( titi )', c'est pour ajouter titi à toto.
Si tu fais 'tutu = toto + titi', c'est pour additionner toto et titi, et mettre le résultat dans tutu. Ni toto ni titi n'a le contrôle de l'opération. Ça n'a donc rien à faire au niveau d'une instance.


(edit - gah, je hais cette option des smileys toujours décochée par défaut)

[rozwel]

Voilà! Ca c'est logique !
Pour autant on surcharge souvent l'opérateur + pour ajouter un élément à une liste par exemple. C'est le vice de la surcharge d'opérateurs. On peut l'utiliser pour faire des choses très différentes sémantiquement. En tout cas, voilà qui répond à ma question... et qui m'incite à ne jamais utiliser la surcharge d'opérateurs en C#