Stilfrage: statische Methoden und Attribute auf jeden Fall verhindern?

[anp]

Hi,

angelehnt an meine andere Stilfrage möchte ich ein leidiges Thema wieder aufgreifen.

Oft heißt es, dass static kein guter Stil ist und auf jeden Fall verhindert werden soll, wenn es nicht zu verhindern ist. Meist schafft man es, alle Methoden dynamisch zu gestalten, notfalls mit speziellen Konstruktoren, jedoch ist das manchmal ein in meinen Augen unnötiger Aufwand, dazu möchte ich ein paar Beispiele bringen:

Fall 1: Methode zum Prüfen eines Strings auf einen int-Wert
Nun habe ich eine Klasse, die lediglich diese Methode enthält: Parameter String, return boolean. Welchen Sinn macht es, die Methode non-static zu machen und sie bei jeder Anwendung initialisieren zu müssen? Es gibt keine Klassenattribute, die bei Nebenläufigkeit ein Problem darstellen könnten.
Zugegeben, hier ist der Mehraufwand nicht unbedingt vorhanden.

Fall 2: Methode zum Erstellen einer noch nicht definierten Instanz
Klassen B und C erben von Klasse A, eine (statische) Methode in Klasse A entscheidet, welche spezielle Klasse nun instantiiert wird und gibt sie zurück. Klasse A ist abstract.
Hier wird es nun pikant: muss ich nun eine spezielle Klasse instantiieren (fragt sich nur welche), um die Methode aufzurufen, die mir die eigentlich gewollte Instanz zurückliefert? Oder soll ich diese ganze Methode in eine externe Klasse auslagern, was in meinen Augen noch unsinniger ist?

Was sagt ihr dazu?

VG

 

[Marco13]

Zwischen Methoden und Attributen ist da ein gewaltiger Unterschied!

Meine "Faustregel" ist:
Methoden sollte man statisch machen, wenn man sie ohne Verrenkungen statisch machen KANN,
Variablen sollte man NUR statisch machen, wenn man sie unbedingt statisch machen MUSS (und das muss man fast nie)

So eine Int-Prüf-Funktion ist eine Utility-Methode, die keinen Zustand braucht - sollte also auf jeden Fall statisch sein.

Das zweite ist wohl ein Fall für eine (Abstract) Factory (Websuche)

 

[anp]

Bei der Überlegung für sinnvolle statische Attribute ist mir nichts gescheites eingefallen, deshalb hab ich auch dazu kein Beispiel gebracht 😉

zu Fall 2 habe ich ein konkretes Anwendungsbeispiel, das mit Factory nur einen Sinn machen würde, wenn ich wirklich eine Factory-Klasse mit der genannten Methode realisiere: ich habe eine abstrakte Benutzerklasse und spezialisierte Benutzer, zudem gibt es nur sozusagen nur eine Factory -> meine Anwendung an sich. Damit bin ich wieder bei einer Methode, die die Unterscheidung übernimmt und ob diese Methode in der Benutzerklasse statisch vorhanden ist oder in einer Factory-Klasse meinetwegen non-statisch ist: ich sehe nicht den Vorteil, das auszulagern 🙁

 

[Marco13]

Nun, irgendwo muss die ENTSCHEIDUNG, welche Instanz erzeugt wird, getroffen werden. Aber egal, wo diese Entscheidung getroffen wird: Wenn an irgendeiner Stelle ein "Benutzer" erzeugt werden muss, aber die Entscheidung darüber, welche Art von Benutzer das sein soll, an einer ANDEREN Stelle getroffen werden soll, dann verwendet man eine Factory...

 

[anp]

Okay, das leuchtet ein. Ist es denn stilistisch in Ordnung, diese Entscheidungsmethode statisch in der Benutzerklasse zu implementieren?

 

[Spacerat]

Ich hab' da im Allgemeinen auch eine "Faustregel":
1. Hauptsache Funktion! Als erstes muss man sich über die Funktion einer Klasse sammt Attribute und und Methoden im Klaren sein. Hier erfährt man eigentlich schon automatisch, od das ein oder andere besser statisch implementiert werden sollte.
2. Ist die Funktion erstmal hergestellt, kann man sich Gedanken über seinen bzw. eines allgemeinen Programmierstil(s) machen. Meistens kommt man aber schon bei 1. darauf, wie man am besten implementiert.
Beispiele für Beides (statische Methoden und statische Attribute) gibt es wie Sand am Meer.
Beispiel für statische Methode(n): Man schaue sich mal die Klasse "java.lang.Math" an.
Beispiel für statische(s) Attribut(e): Instanzierungszähler einer Klasse. Jemand kann ja mal versuchen, einen solchen anders hin zu bekommen.