Sind "Plus" und "Minus" geeignete Methodennamen?


21

Java SE 8 kommt mit einem neuen Mechanismus für Daten, die Einführung LocalDate, LocalTimeund LocalDateTimeKlassen Zeitmomente darzustellen. Um einen solchen Zeitpunkten eine Reihe von Methoden zu manipulieren sind gegeben: LocalDate.plusDays(...), LocalDate.minusDays(...)und so weiter.

Ich habe immer gedacht, dass gute Praxis darin besteht, Methoden nach Verben zu benennen, die ihren Zweck beschreiben, da Methoden tatsächlich auszuführende Operationen sind, die eine Aktion ausführen . Nur zu erwähnen, wenn Sie Klassen wie betrachten StringBuilder, zum Beispiel Methoden Namen sind append, insert, delete...

Aus diesem Grunde ist es mir nicht richtig klingen , ein Verfahren zu benennen plusDaysstatt sumDays, minusDaysstatt subtractDays. Ich finde es nur sehr ärgerlich? Was denkst du?

Der einzige Grund, den ich mir vorstellen kann, ist, dass Datumsangaben unveränderliche Objekte sind. Wenn Sie also aufrufen plusDays, fügen Sie dem ursprünglichen Objekt keine Tage hinzu, sondern erstellen ein neues Objekt mit neuen Eigenschaften. Dies ist jedoch sehr subtil.


22
Ich denke, Sie sehen das zu technisch. Das eigentliche Ziel für Methodennamen ist es, die Funktionsweise zu verdeutlichen und lesbar zu machen. Es stellt sich nur heraus, dass die Benennung mit Verben normalerweise diese beiden Ziele erreicht. Betrachten Sie jedoch eine Methode namens, sqrtdie die Quadratwurzel nimmt. Die Benennung dieser Methode takeSqrtmag nach Ihrer Regel sinnvoll erscheinen, aber die Benennung würde die Methode weder lesbarer noch klarer machen.
Brandin

2
Die Programmierung ist nicht "Englisch". Zum Beispiel sqrtist es nur ein Wort, das Programmierer erkennen und kennen müssen. Das englische Wort ist übrigens "Quadratwurzel". Aber Dinge nach dem zu benennen, was im Englischen selbstverständlich ist, ist nicht gut. Nehmen wir zum Beispiel das Wort "illegal", ein perfektes englisches Wort. Wenn jedoch jemand seine Methode benennt, kann isIllicitich sagen, dass ich bei jedem Blick auf diesen Methodenaufruf meine Augäpfel herausreißen möchte. Es sieht einfach schrecklich aus und es muss einen besseren Weg geben, die Idee auszudrücken.
Brandin

18
sumklingt in diesem Zusammenhang falsch. Ich bevorzuge .net AddDays.
CodesInChaos

3
@LuigiCortese Die Methodennamen werden so ausgewählt, dass sie der üblichen englischen Wortreihenfolge entsprechen. Math.addExact(1, 2)weil du sagst "addiere 1 und 2". tomorrow.plusDays(2)weil du sagst "morgen plus 2 tage". Wenn addExactein Mitglied von Integerirgendwie gewesen wäre, wäre es gewesen 1.plusExact(2).
Tavian Barnes

8
Persönlich würde ich erwarten plusDays, ein neues Datum x Anzahl von Tagen in die Zukunft zurückzugeben, wohingegen addDaysich erwarten könnte, das ursprüngliche Objekt zu mutieren. Das bin nur ich, ich kenne mich mit Java nicht so gut aus.
Ajedi32

Antworten:


52

Der einzige Grund, den ich mir vorstellen kann, ist, dass Datumsangaben unveränderliche Objekte sind. Wenn Sie also plusDays aufrufen, fügen Sie dem ursprünglichen Objekt keine Tage hinzu, sondern erstellen ein neues Objekt mit neuen Eigenschaften.

Das ist genau der Grund. Stellen Sie sich vor, Sie hätten eine Art API, um Datumsbereiche für Planungszwecke zu bearbeiten. Möglicherweise werden Methoden angezeigt, mit denen Sie eine Aussage machen können wie:

var workdaySchedule = initialSchedule.withoutWeekends();

Dies liest sich sehr ähnlich wie die englische Aussage: "Der Arbeitstag-Zeitplan ist der ursprüngliche Zeitplan ohne Wochenenden". Dies bedeutet nicht, dass der anfängliche Zeitplan geändert wird, sondern dass der Arbeitszeitplan eine andere, neue Sache ist.

Stellen Sie sich stattdessen vor, es wurde benannt:

var workdaySchedule = initialSchedule.removeWeekends();

Das ist verwirrend. Wird der ursprüngliche Zeitplan geändert? Es klingt auf jeden Fall so, denn es klingt so, als würden wir die Wochenenden davon abhalten. Aber warum ordnen wir es dann einer neuen Variablen zu? Obwohl diese beiden Benennungsschemata sehr ähnlich sind, ist dieses viel weniger deutlich, was passiert. Dies wäre besser geeignet , wenn removeWeekends tat den ursprünglichen Zeitplan ändern, und kehrte void- wobei in diesem Fall withoutWeekendsdie verwirrende Option wäre.


Dies ist im Wesentlichen eine Unterscheidung zwischen deklarativ und imperativ. Erklären wir , dass dieworkdaySchedule eine bestimmte Sache ist, oder führen wir eine Liste von zwingenden Anweisungen (wie "Entfernen") aus, um diese bestimmte Sache zu machen? Normalerweise ist die imperative Benennung sinnvoller, wenn Sie Werte ändern, und die deklarative Benennung ist sinnvoller, wenn Sie unveränderliche Werte verwenden, wie das obige Beispiel zeigt.

In Ihrem Fall haben Sie genau das gleiche. Wenn ich sehen tomorrow.plusDayswürde, würde ich mir nicht vorstellen, dass tomorrowdas mutiert ist, obwohl tomorrow.addDaysich denke, dass es das sein könnte. Das ist etwas subtil, aber nicht unbedingt schlecht. Ohne zu sehr darüber nachdenken zu müssen, setzt diese Benennung Ihr Denken natürlich in Bezug darauf, ob Sie mutieren oder nicht, in die richtige Richtung. Um diese Unterscheidung zwischen imperativem und deklarativem Stil deutlicher zu machen: "add" (und "remove") sind Verben , wohingegen "plus" (und "without") Präpositionen sind .


13
Ich hatte tatsächlich ein Problem mit addDaysgegenüber plusDaysgestern! In .NET, das DateTimehat Klasse Methoden genannt addDays, addMonthsund addYears. Ich habe eine Methode zum Auslesen eines relativen Datums (vor 1 Jahr, 2 Monaten, 3 Tagen) erstellt und die oben genannten Methoden aufgerufen, in der Annahme, dass sie das aktuelle DateTimeObjekt modifizieren . Jedes Datum in der Datenbank war der 8. Juni 2015. "Das ist lustig", dachte ich. Das war, als ich mich erinnerte, dass addDaysdas DateTimeObjekt nicht geändert wurde , sondern ein neues zurückgegeben wurde . Für diese Frage gibt es also überall +1.
Greg Burghardt

1
@ GregBurghardt Als .NET-Benutzer habe ich genau entgegengesetzte Erwartungen. Ich denke, dies bedeutet nur, dass "plus" und "add" austauschbar sind, nicht direkte Zuordnungen zu +und+=
Agent_L

2
@ Agent_L Das ist interessant. Abgesehen von .NET-Konventionen sind "add" und "plus" in Englisch nicht austauschbar.
Ben Aaronson,

1
Auch für Datums- und Uhrzeitangaben ist es üblich, von D + 1, H + 12 usw. zu sprechen, um die Zeit relativ zu einem bestimmten Ursprung zu referenzieren (auch für den Raumflug T-10, T-9 usw.). Üblicherweise wird dies als D-plus-1, H-plus-12, T-minus-10 gelesen. Vielleicht in den USA, aber so erscheint es mir.
Kristian H

4
Vielleicht finden Sie diese alte StackOverflow-Frage von Jon Skeet interessant: Wie lautet der beste Name für eine nicht mutierende "add" -Methode in einer unveränderlichen Sammlung? .
MicSim,

2

In .NET ist die Benennung unterschiedlich, obwohl das Ergebnis genau gleich ist. Anstatt:

tomorrow = LocalDateTime.plusDays(1);

es gibt:

tomorrow = DateTime.Now.AddDays(1);

Dies bedeutet nur, dass Unterschiede zwischen dem Verständnis von "Plus" und "Addieren" als Frage der persönlichen Meinung entstanden sind. Aufmuntern, du bist nicht allein, zumindest kannst du die Sprache wählen, die dich besser anspricht:)


-1

Dies ist wahrscheinlich ein Artefakt von Java, das .Methodfür alle Methoden verwendet wird, sowohl für diejenigen, die das Objekt ändern, als auch für diejenigen, die dies nicht tun.

Stellen Sie sich eine Sprache , die auch eine hat object=>methodSyntax, die geben würde , methodauf einer Kopie des Objekts an der Arbeit. Jetzt in einer solchen Sprache,startDate=>plusDays(5) eindeutig. Es wird das ursprüngliche Datum verwendet und ein neues Datum erstellt, das 5 Tage später liegt.

In einem anderen sumDaysSinne ergibt das hier keinen Sinn. LocalDateist ein Zeitpunkt , eine Zeit , nicht Dauer . Sie können eine beliebige Anzahl von Dauern summieren (und das Ergebnis ist eine andere Dauer) und Sie können einen Zeitpunkt und eine Dauer hinzufügen (Ergebnis ist ein anderer Zeitpunkt), aber Sie können keine Zeitpunkte summieren.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.