Les noms de méthode «plus» et «moins» sont-ils appropriés?

Java SE 8 est livré avec un nouveau mécanisme pour les dates, l' introduction LocalDate, LocalTimeet des LocalDateTimeclasses pour représenter instants de temps. Pour manipuler ces instants, un ensemble de méthodes sont données: LocalDate.plusDays(...), LocalDate.minusDays(...)et ainsi de suite.

J'ai toujours pensé que la bonne pratique consistait à nommer les méthodes après des verbes décrivant leur objectif, car les méthodes sont, en fait, des opérations à exécuter, quelque chose qui exécutera une action. Il suffit de mentionner, si l' on considère les classes comme StringBuilder, par exemple, les noms de méthodes sont append, insert, delete...

C'est pourquoi pour moi cela ne sonne pas juste de nommer une méthode plusDaysau lieu de sumDays, minusDaysau lieu de subtractDays. C'est juste que je trouve ça très ennuyeux? Qu'est-ce que tu penses?

La seule raison pour laquelle je peux penser est que les dates sont des objets immuables, donc en appelant, plusDaysvous n'ajoutez pas de jours à l'objet d'origine mais en créez un nouveau avec de nouvelles propriétés, mais c'est très très subtil.

java methods naming-standards

— Luigi Cortese
source

Je pense que vous regardez cela trop techniquement. Le but réel des noms de méthode est de clarifier ce qu'elle fait et de le rendre lisible. Il s'avère que les nommer avec des verbes accomplit normalement ces deux objectifs. Cependant, considérons une méthode appelée sqrtqui prend la racine carrée. Nommer cette méthode takeSqrtpeut sembler logique selon votre règle, mais la nommer ne rendra pas la méthode plus lisible ni plus claire.

— Brandin

La programmation n'est pas "anglaise". Par exemple, ce sqrtn'est qu'un mot que les programmeurs doivent reconnaître et connaître. Le mot anglais est "racine carrée" soit dit en passant. Mais nommer les choses en fonction de ce qui est naturel en anglais n'est pas bon. Prenez le mot «illicite», par exemple, un mot anglais parfaitement fin. Cependant, si quelqu'un a nommé sa méthode, disons que isIllicitje pense que je voudrais arracher mes globes oculaires chaque fois que je regarde cet appel de méthode. Cela a l'air horrible et il doit y avoir une meilleure façon d'exprimer l'idée.

— Brandin

sumsonne mal dans ce contexte. Je préfère les .net AddDays.

— CodesInChaos

@LuigiCortese Les noms de méthode sont choisis pour correspondre à l'ordre des mots anglais courants. Math.addExact(1, 2)parce que vous dites "ajoutez 1 et 2". tomorrow.plusDays(2)parce que vous dites "demain plus 2 jours". Si j'avais addExactété membre d'une Integermanière ou d'une autre, cela aurait été le cas 1.plusExact(2).

— Tavian Barnes

Personnellement, je m'attendrais plusDaysà retourner une nouvelle date x nombre de jours dans le futur, alors que addDaysje pourrais m'attendre à muter l'objet d'origine. C'est juste moi cependant, je ne suis pas très familier avec Java.

— Ajedi32

Réponses:

La seule raison pour laquelle je peux penser est que les dates sont des objets immuables, donc en appelant plusDays, vous n'ajoutez pas de jours à l'objet d'origine mais en créez un nouveau avec de nouvelles propriétés, mais cela varie très subtilement.

C'est exactement la raison. Imaginez que vous disposiez d'une sorte d'API pour manipuler des plages de dates à des fins de planification. Il peut exposer des méthodes vous permettant de faire une déclaration comme:

var workdaySchedule = initialSchedule.withoutWeekends();

Cela se lit de manière très similaire à la déclaration en anglais: "L'horaire de travail est l'horaire initial sans week-end". Cela n'implique pas de modifier l'horaire initial, cela implique que l'horaire de travail est une chose nouvelle et différente.

Imaginez maintenant qu'il s'appelle:

var workdaySchedule = initialSchedule.removeWeekends();

Ceci est déroutant. L'horaire initial est-il en train d'être modifié? Cela ressemble certainement à cela, car il semble que nous en supprimions les week-ends. Mais alors pourquoi l'attribuons-nous à une nouvelle variable? Bien que ces deux schémas de dénomination soient très similaires, celui-ci évoque beaucoup moins clairement ce qui se passe. Ce serait plus approprié si removeWeekends cela changeait le calendrier initial et renvoyait le vide - auquel cas ce withoutWeekendsserait une option déroutante.

Il s'agit essentiellement d'une distinction déclarative vs impérative. Est -ce que nous annonçons que la workdayScheduleest une chose particulière, ou sommes - nous menons une liste des impératifs instructions pour faire cette chose en particulier (comme « enlever »)? Habituellement, la dénomination impérative a plus de sens lorsque vous mutez des valeurs et déclarative a plus de sens avec des valeurs immuables, comme le montre l'exemple ci-dessus.

Dans votre cas, vous avez exactement la même chose. Si je voyais:, tomorrow.plusDaysje n'imaginerais pas que cela tomorrowest en train de muter, alors que tomorrow.addDaysje pense que c'est possible. C'est quelque peu subtil, mais pas nécessairement dans le mauvais sens. Sans avoir à y penser trop fort, cette dénomination oriente naturellement votre réflexion dans la bonne direction en termes de mutation. Pour clarifier cette distinction entre ces styles impératifs et déclaratifs: "ajouter" (et "supprimer") sont des verbes , tandis que "plus" (et "sans") sont des prépositions .

— Ben Aaronson
source

J'ai eu un problème avec addDaysversus plusDayshier! Dans .NET, la DateTimeclasse a des méthodes appelées addDays, addMonthset addYears. J'ai créé une méthode pour analyser une date relative (il y a 1 an, 2 mois, 3 jours) et j'ai appelé les méthodes susmentionnées en pensant qu'elles modifiaient l' DateTimeobjet actuel . Chaque date dans la base de données a fini par être le 8 juin 2015. «C'est drôle», ai-je pensé. C'est alors que je me suis souvenu que addDayscela ne modifie pas l' DateTimeobjet, il en renvoie un nouveau . Donc, +1 est tout autour pour cette question.

— Greg Burghardt

@GregBurghardt En tant qu'utilisateur .NET, j'ai des attentes exactement opposées. Je suppose que cela signifie seulement que "plus" et "ajouter" sont échangeables, pas des mappages directs vers +et+=

— Agent_L

@Agent_L C'est intéressant. Les conventions .NET mises à part, "ajouter" et "plus" ne sont pas interchangeables en anglais.

— Ben Aaronson

De plus, pour les dates et les heures, il est courant de parler de J + 1, H + 12 et ainsi de suite pour référencer le temps par rapport à une origine spécifique (également, pour le vol spatial T-10, T-9, etc.). Généralement, cela se lit comme D-plus-1, H-plus-12, T-moins-10. Peut-être centré sur les États-Unis, mais c'est ainsi que cela me semble.

— Kristian H

Vous pourriez trouver cette vieille question StackOverflow de Jon Skeet intéressante: Quel est le meilleur nom pour une méthode "add" non mutante sur une collection immuable? .

— MicSim

Dans .NET, la dénomination est différente bien que le résultat soit exactement le même. Au lieu de:

tomorrow = LocalDateTime.plusDays(1);

il y a:

tomorrow = DateTime.Now.AddDays(1);

Cela signifie seulement que les différences entre la compréhension de «plus» et «ajouter» sont devenues une question d'opinion personnelle. Réjouissez-vous, vous n'êtes pas seul, au moins vous pouvez choisir la langue qui vous convient le mieux :)

— Agent_L
source

-1

Il s'agit probablement d'un artefact que Java utilise .Methodpour toutes les méthodes, à la fois celles qui modifient l'objet et celles qui ne le font pas.

Imaginez un langage qui possède également une object=>methodsyntaxe, qui donnerait methodune copie de l'objet à travailler. Maintenant, dans une telle langue, startDate=>plusDays(5)est clairement sans ambiguïté. Il prend la date d'origine et crée une nouvelle date qui est 5 jours plus tard.

Sur une note indépendante, cela sumDaysn'a pas de sens ici. LocalDateest un point temporel , pas une durée . Vous pouvez additionner n'importe quel nombre de durées (et le résultat est une autre durée), et vous pouvez ajouter un point temporel et une durée (le résultat est un autre point temporel), mais vous ne pouvez pas additionner des points temporels.

— MSalters
source