Gibt es eine bewährte Methode für die Reihenfolge, in der Getter und Setter definiert werden? Es scheint zwei Praktiken zu geben:
- Getter / Setter-Paare
- Erst Getter, dann Setter (oder umgekehrt)
Um den Unterschied zu verdeutlichen, hier ein Java-Beispiel für Getter / Setter-Paare:
public class Foo {
private int var1,
var2,
var3;
public int getVar1() {
return var1;
}
public void setVar1(int var1) {
this.var1 = var1;
}
public int getVar2() {
return var2;
}
public void setVar2(int var2) {
this.var2 = var2;
}
public int getVar3() {
return var3;
}
public void setVar3(int var3) {
this.var3 = var3;
}
}Und hier ist ein Java-Beispiel für first getters, then setters:
public class Foo {
private int var1,
var2,
var3;
public int getVar1() {
return var1;
}
public int getVar2() {
return var2;
}
public int getVar3() {
return var3;
}
public void setVar1(int var1) {
this.var1 = var1;
}
public void setVar2(int var2) {
this.var2 = var2;
}
public void setVar3(int var3) {
this.var3 = var3;
}
}Ich denke, die letztere Art der Bestellung ist sowohl im Code als auch in den Klassendiagrammen klarer, aber ich weiß nicht, ob dies ausreicht, um die andere Art der Bestellung auszuschließen.
Wenn Sie in einem Team sind, tun Sie das, was sie normalerweise tun. Andernfalls wählen Sie einfach die aus, die Ihnen besser gefällt. Auf der Skala wichtiger Designentscheidungen ist dies wahrscheinlich in der Nähe von "Mit welchem Daumen soll ich die Leertaste drücken?".
quelle
Dies kann auch von der Sprache abhängen. In Java gibt es keinen wirklichen Vorteil für eine der beiden Reihenfolgen, aber in C # haben Sie zum Beispiel das Konzept von "Eigenschaften", die den Getter und den Setter zusammenfassen, sodass diese Reihenfolge erzwungen wird. In einer Sprache wie C ++, in der Sie möglicherweise eine andere Sichtbarkeit für Getter als Setter wünschen (z. B. Private Setter, Public Getter), würden Sie wahrscheinlich das Gegenteil tun, da der Sichtbarkeitsmodifikator für mehrere Methoden einmal und nicht für jede Methode einzeln angegeben wird .
quelle
Soweit ich weiß, gibt es keine einzige Konvention. Im Abschnitt Oracle Java Code Conventions zur Dateiorganisation wird die Platzierung von Gettern und Setzern nicht explizit erwähnt, es heißt jedoch:
Dies ist keine Anleitung - ich könnte argumentieren, dass beide Platzierungen diese Kriterien erfüllen.
Zu berücksichtigen ist, dass Sie mit modernen IDEs abstraktere Ansichten der Struktur Ihrer Dateien erhalten als mit der textuellen Codekomponente. Zusammen mit leistungsstarken Suchwerkzeugen sollte dies das Navigieren in Dateien und das Auffinden der entsprechenden Methoden auch in großen Dateien vereinfachen.
Eclipse bietet beispielsweise eine Gliederungsansicht, in der Sie Methoden und Felder auf verschiedene Arten sortieren und filtern und direkt zu den Positionen in Dateien navigieren können. NetBeans hatten eine ähnliche Funktionalität, und ich würde vermuten, dass die meisten anderen IDEs dies auch tun.
Dies ist möglicherweise nur dann von Bedeutung, wenn Sie den Code außerhalb Ihrer IDE lesen. Ein Beispiel ist die Verwendung eines externen Tools zur Codeüberprüfung oder das Anzeigen von Deltas in Ihrem Versionskontrollsystem.
Die beste Lösung wäre, einfach über alle Dateien in einem Projekt hinweg konsistent zu sein. Suchen Sie einen Standard, dokumentieren Sie ihn und halten Sie sich daran.
quelle
Gruppieren Sie den Getter und Setter für ein einzelnes Feld paarweise.
Das Gruppieren aller Getter und Setter macht es schwierig zu sagen, welche Felder nur Getter oder nur Setter haben.
Wenn ich Code lese oder nach einer bestimmten Funktionalität suche, stelle ich mir eine Klasse mit Feldern vor, wobei jedes Feld einen Getter und einen Setter hat. Es macht für mich keinen Sinn, dass eine Klasse eine Get-Gruppe und eine Set-Gruppe hat, die jeweils Felder haben.
quelle
Jede Java-IDE kann Getter und Setter für Sie generieren. Verwenden Sie einfach diese Funktionalität und lassen Sie die Reihenfolge der Methoden so, wie sie von der IDE erstellt wurden. Dies ist generierter Code, berühren Sie ihn nicht unnötig.
quelle