Bisher habe ich es so gehandhabt, dass ich nach Möglichkeit statische Methoden in “echten” Klassen (also solchen, die nicht eine Tool-Sammlung ohne eigene Daten sind, wie Math) vermieden habe. Trotzdem gibt es dort Methoden, die nicht auf den Membern der Klasse arbeiten, sondern etwas als Parameter übergeben bekommen und einen Wert zurückliefern.
Wäre es nun aus irgendwelchen Gründen schöner / eleganter / überlegenswert, diese Methoden statisch zu machen?
Mir fallen keine ein 
Das hört sich ein bisschen so an, als ob die Methode dann nix mit der Klasse zu tun hat und eigentl. auch ausgelagert werden kann in eine solche Tool- Klasse.
Hast du ein Beispiel für solch eine Methode?
In einem Fall ist es so, dass eine Datei eingelesen wird in eine Liste von Objekten, die den Daten einer Zeile entsprechen. Später werden dann Verzeichnisse (Map) basierend auf diesen Daten aufgebaut. Member der Klasse sind nur diese Verzeichnisse. Das Einlesen findet also unabhängig von diesen Membern statt, gehört aber thematisch sehr wohl zu der Klasse.
[QUOTE=maki]
Wäre es nun aus irgendwelchen Gründen schöner / eleganter / überlegenswert, diese Methoden statisch zu machen?
Mir fallen keine ein :)[/QUOTE]
Wie würdest du das handhaben, wenn Methoden „von Natur aus“ static wären, und erst durch einen expliziten Modifier zu Instanzmethoden gemacht werden müßten?
class SomeClass {
// Sei die mal "implizit statisch":
int someMethod(int a) {
return 2*a;
}
}
→
class SomeClass {
// Nein, die soll eine Instanzmethode von "SomeClass" sein!!!111elf
int SomeClass::someMethod(int a) {
return 2*a;
}
}
?
Ich habe die Daumenregel: Wenn eine Methode „einfach so“ static sein kann, dann sollte sie es auch sein (also wenn man sich dafür nicht verbiegen und 20 Parameter übergeben muss). Schon allein um auf den ersten Blick unmißverständlich klar zu machen: „Diese Methode hat nichts mit den Fields (d.h. dem Zustand!) dieser Klasse zu tun“.
Man könnte/sollte das aber weiter ausdifferenzieren: Letztendlich ist das keine auf rein syntaktischer Ebene zu treffende Entscheidung, sondern hängt davon ab, ob die Methode private, default, protected abstract, protected final, public final oder public abstract ist oder sein sollte (also grob: Welche Rolle sie bei Vererbungen spielen soll). (Nebenbei: protected oder public alleine tauchen in dieser Liste absichtlich nicht auf ;))
Bei mir geht es dabei um Methoden, die private sind.
Müsste man Methoden explizit nicht-statisch machen, würde ich das vermutlich nicht tun.
Das habe ich eigentlich nie
Liegt aber imer an dem konkreten Problem bzw. der Problemdomaene, habe selber nie was mit Mathe etc. in meinen Anwendungen zu tun, alles „Bussiness Zeug“, da habe ich immer einen internen Zustand.
Das mag in anderen Problemdomaenen ganz anders sein.
Ich finde, bei privaten Methoden ist die Entscheidung leicht: Ich würde so eine Methode immer static machen, weil sie ja nichts mit der Instanz zu tun hat (und … wenn sie static ist, auch von einer anderen static-Methode aufgerufen werden kann :D)
Na ist doch wie bei finalen Klassenvariablen oder const Parametern in C++: Natürlich muss man es nicht, aber es signalisiert dem Aufrufer eine gewisse Invariante; im gefragten Fall, dass keine Klassenvariable genutzt wird. Und zu sagen, das sollte dann gleich in eine andere Klasse, halte ich für Quark. Der Code muss ja nicht wiederverwendbar sein (rule of three usw.)
Gut, danke. Dann werde ich das beim Refactoring mal mit übernehmen.