Y a-t-il un inconvénient à renvoyer ceci au lieu de void ?

Question

Supposons qu'au lieu de renvoyer une méthode void, vous ayez renvoyé une référence à la classe même si cela n'avait aucun sens sémantique particulier.Il me semble que cela vous donnerait plus d'options sur la façon dont les méthodes sont appelées, vous permettant de l'utiliser dans un style semblable à celui d'une interface fluide et je ne vois pas vraiment d'inconvénients puisque vous n'avez rien à faire. avec la valeur de retour (même la stocker).

Supposons donc que vous soyez dans une situation où vous souhaitez mettre à jour un objet, puis renvoyer sa valeur actuelle.au lieu de dire

myObj.Update();
var val = myObj.GetCurrentValue();

tu pourras combiner les deux lignes pour dire

var val = myObj.Update().GetCurrentValue();

---

MODIFIER: J'ai posé la question ci-dessous sur un coup de tête, rétrospectivement, je conviens que cela sera probablement inutile et compliqué, mais ma question concernant le retour de cela plutôt que d'être nulle est valable.

Dans le même ordre d'idées, que pensez-vous du fait que le langage inclut un nouveau morceau de sucre syntaxique :

var val = myObj.Update()<.GetCurrentValue();

Cet opérateur aurait un ordre de priorité faible, donc myObj.Update() s'exécuterait en premier, puis appellerait GetCurrentValue() sur myObj au lieu du retour nul de Update.

Essentiellement, j'imagine un opérateur qui dira "appeler la méthode à droite de l'opérateur sur le premier objet valide à gauche".Des pensées?

Answer 1

Je sais qu'en Java, ils envisagent actuellement de créer ce comportement standard pour les méthodes void.Si vous faites cela, vous n’avez pas besoin de sucre syntaxique supplémentaire.

Le seul inconvénient auquel je pense est la performance.Mais c'est facile à mesurer.Je vous reviens avec les résultats dans quelques minutes :-)

Modifier:

Renvoyer une référence est un peu plus lent que renvoyer void ..quelle surprise.C'est donc le seul inconvénient.Quelques ticks supplémentaires lors de l'appel de votre fonction.

Answer 2

Je pense qu'en termes de politique générale, cela n'a tout simplement pas de sens.Le chaînage de méthodes de cette manière fonctionne avec une interface correctement définie, mais il n'est approprié que s'il a un sens sémantique.

Votre exemple est un excellent exemple où il n'est pas approprié, car il n'a aucun sens sémantique.

De même, votre sucre syntaxique n’est pas nécessaire avec une interface fluide correctement conçue.

Interfaces fluides ou chaînage de méthodes peut fonctionnent très bien, mais doivent être conçus avec soin.

Answer 3

N'est-ce pas ainsi que sont construites les « interfaces fluides » - comme celles utilisées par JQuery ?L'un des avantages est censé être la lisibilité du code (bien que l'entrée Wikipédia à l'adresse http://en.wikipedia.org/wiki/Fluent_interface mentionne que certains le trouvent PAS lisible).Un autre avantage réside dans la concision du code, vous n'avez plus besoin de définir des propriétés sur 7 lignes de code, puis d'appeler une méthode sur cet objet dans la 8ème ligne.

Martin Fowler (qui a inventé le terme ici - http://martinfowler.com/bliki/FluentInterface.html) indique que les interfaces fluides ne se limitent pas au chaînage de méthodes, mais le chaînage de méthodes est une technique courante à utiliser avec des interfaces fluides.

MODIFIER:En fait, je revenais ici pour modifier ma réponse et ajouter qu'il n'y a aucun inconvénient à renvoyer ceci au lieu de void de manière mesurable, quand j'ai vu le commentaire de George soulignant que j'avais oublié de discuter du indiquer de la question.Désolé pour les premières divagations "inutiles".

Answer 4

Renvoyer « soi » ou « ceci » est un modèle courant, parfois appelé "enchaînement de méthodes".Quant au sucre de syntaxe que vous proposez, je n'en suis pas si sûr.Je ne suis pas un gars .NET, mais cela ne me semble pas très utile.

Answer 5

Le framework NeXTSTEP Objective-C utilisé pour utiliser ce modèle.Il a été abandonné dans ce cadre une fois que des objets distribués (appels de procédure à distance, essentiellement) ont été ajoutés au langage - une fonction qui renvoyait self devait être une invocation synchrone, puisque le système d'objets distribués voyait le type de retour et supposait que l'appelant aurait besoin de connaître le résultat de la fonction.

Answer 6

Le seul inconvénient que je vois est que cela rend l'API légèrement plus déroutante.Disons que vous avez un objet de collection avec une méthode remove() qui renverrait normalement void.Vous souhaitez maintenant renvoyer une référence à la collection elle-même.La nouvelle signature ressemblerait à :

public MyCollection remove(Object someElement)

En regardant simplement la signature, il n'est pas clair que vous renvoyez une référence à la même instance.Peut-être que MyCollection est immuable et que vous renvoyez une nouvelle instance.Dans certains cas, comme ici, vous aurez besoin d'une documentation externe pour clarifier cela.

En fait, j'aime cette idée, et je crois qu'il a été question de moderniser toutes les méthodes void dans Java7 pour renvoyer une référence à « ceci », mais cela a finalement échoué.

Answer 7

À première vue, cela peut paraître bien, mais pour une interface cohérente, vous aurez besoin que toutes les méthodes renvoient une référence à ceci (ce qui pose ses propres problèmes).

Disons que vous avez une classe avec deux méthodes GetA qui renvoient ceci et GetB qui renvoient un autre objet :

Ensuite, vous pouvez appeler obj.GetA().GetB(), mais pas obj.GetB().GetA(), ce qui au moins ne semble pas cohérent.

Avec Pascal (et Visual Basic) vous pouvez appeler plusieurs méthodes d'un même objet.

with obj
  .GetA();
  .GetB();
end with;

Le problème avec cette fonctionnalité est que vous pouvez facilement écrire du code plus difficile à comprendre qu’il ne devrait l’être.De plus, l'ajout d'un nouvel opérateur rend probablement les choses encore plus difficiles.