Static oder wie?

[Verjigorm]

Moin,

ich hab momentan folgendes nonkretes Problem:

Ich habe ein Programm mit komplizierter teilweise selbstgezeichneter GUI.
Es gibt massig Hilfsklassen, die für die Gui irgendwelche Dinge berechnen,ausrichten,verändern oder sonstwas machen.
Da ich es eigentlich relativ unnötig finde, von jede dieser Hilfsklassen (momentan etwa ein Dutzend, werden wohl noch mehr) eine Instanz anzulegen, habe ich mir überlegt, ob ich das ganze nicht in statische Funktionen verpacke.
Aber da hier im Forum immer wieder auf OOP hingewiesen wird, wollte ich mal eure Meinung dazu einholen.

Für den Objektgedanken spricht für mich eigentlich nix, was meint ihr dazu?

mfg Verjigorm

 

[SlaterB]

Hilfsoperationen passen immer gut statisch,
siehe die Math.xy(), Arrays.xy(), Collections.xy()-Operationen usw.

mach alles nur dann nicht-statisch, wenn es einen guten Grund gibt,
OOP ist kein Selbstzweck

 

[PollerJava]

mach alles nur dann nicht-statisch, wenn es einen guten Grund gibt,

Das ist mal ein anderer Ansatz, ich hab auf der UNI immer gehört, nur das static zu machen, was unbedingt notwendig ist, aber ich sehe immer wieder, dass viele Anfänge zu viel static einbauen und somit den OOP- Gedanken nicht mitbekommen,

 

[The_S]

Naja, wenn man OOP kann, dann weiß man auch wo static sinnvoll ist und wo nicht. Was da aber teilweise von Anfängern an static verbaut wird geht auf keine Kuhhaut mehr :roll:

 

[Verjigorm]

Nunja, ich mach eigentlich immer alles OOP

aber hier wäre nun der Fall, dass ich 3/4 aller Methoden static machen würde, da ich einfach das Objekt an sich nicht benötige und die Berechnungen etc. einfach aus der Gui-Klasse auslagern möchte.

Wird das dann "nicht zu viel static" ?

 

[maki]

3/4 ist definitiv zuviel.

Helper Klassen samt Methoden sind eigentlich nie static, zumindest selten.

Allgemeine Utility Methoden dagegen sind meist static.

 

[Verjigorm]

aber was bringt es mir, wenn ich nen Objekt von einer Klasse anlege, die mir lediglich 2 Funktionen bereitstellt?

 

[maki]

"Seperation of Concerns" zum Beispiel

Ist sogar üblich und OO viele Klassen mit wenig Methoden zu haben.

 

[SlaterB]

ob wenig oder viele Operationen hat mit statisch oder Objekt erzeugen nix zu tun

'Separation' übrigens

 

[maki]

ob wenig oder viele Operationen hat mit statisch oder Objekt erzeugen nix zu tun

Natürlich nicht, aber 3/4 statische Methoden hat mit OO nix zu tun

 

[Verjigorm]

"Seperation of Concerns" zum Beispiel

Ist sogar üblich und OO viele Klassen mit wenig Methoden zu haben.

OOOKKK, naja deswegen frag ich ja

Für mich isses nur so, dass die angebotene Funktion quasi kein Bezug zur Klasse hat, deswegen hätte ich alles static gemacht

 

[SlaterB]

immer noch: gerne mag man static an sich verfluchen,
aber mit der Separation hat das nun wirklich nix zu tun

 

[maki]

immer noch: gerne mag man static an sich verfluchen,
aber mit der Separation hat das nun wirklich nix zu tun

Ja, mit static hat das nix zu tun tun.
SoC deswegen weil es nix schlechtes ist, viele Klassen mit wenig Methoden zu haben, siehe vor-vorletzten Post des TS.

 

[Verjigorm]

jojo, ich habs ja verstanden

Wie ist das denn mit Speicherverhalten?
Der Speicherverbrauch ist doch dann so generell gesehen "größer" oder? (auch wenns hier nicht ins Gewicht fällt)

 

[SlaterB]

man ey, hast du keine echten Probleme über die du dir Gedanken machen musst?
die paar Bytes wo jedes Programm standardmäßig schon MegaBytes belegt

 

[quippy]

Die Diskussion über zu viel oder zu wenig statische Methoden verstehe ich echt nicht.

In OOP ist die Klassenmethode genauso berechtigt wie die Instanzmethode.

Eine Instanz benötige ich, wenn meine Klasse eine konkrete Ausprägung haben muss (konkret ist also der Kunde Meier).

Eine Instanzmethode benötigt die konrekte Ausprägung der Klasse (klassisch: getter und setter, oder sowas wie "getFullName()", was Vor- und Nachnamen konkateniert)

Eine Klassenmethode verwende ich immer dort, wo eine konkrete Instanz nicht benötigt wird - die Methode als mit den Instanzvariablen nichts am Hut hat.

Wenn man nun eine Helper-Klasse baut, welche allgemeine Routinen für z.B. die Formatierung eines Datums oder die Berechnung zum zentrieren eines Frames auf einem Parent oder Desktop enthält, dann können alle diese Methoden auch statisch sein. Das widerspricht dem OOP-Gedanken in keinster Weise.

Aufpassen muss man, wenn man diese statischen Methoden nicht in eine Helperklasse auslagert, sondern im konkreten Objekt ablegt, also z.B. eine allgemeine Stringkonkatenierungsroutine für zwei Strings als Static im Kunden-Objekt. Das macht wenig Sinn.
Die nächste Frage ist immer, ob man ein Überschreiben der Methode in Subklassen ermöglichen will. Dann wiederum muss man wohl oder übel ohne static arbeiten. In dem Fall kann man aber auch von einer engen Verknüpfung zwischen der Objektinstanz und der Methode sprechen.

Wenn man desweiteren beherzigt, den Klassennamen vor die statische Methode zu schreiben, fällt während dem Coding eigentlich schnell auf, ob man da nun ein Designproblem hat oder nicht.

 

[Verjigorm]

Wenn man nun eine Helper-Klasse baut, welche allgemeine Routinen für z.B. die Formatierung eines Datums oder die Berechnung zum zentrieren eines Frames auf einem Parent oder Desktop enthält, dann können alle diese Methoden auch statisch sein. Das widerspricht dem OOP-Gedanken in keinster Weise.

Genau deswegen wollte ich diese Funktionen static machen, weil sie einfach nur berechnungen etc ausführen, so wie es die Funktionen von Math auch tun
Werte rein, neue Werte raus. Deswegen seh ich hier Sinn nicht, Instanzen anzulegen

 

[PollerJava]

Mal so ein Einwurf von mir, man könnte ja auch lauter Singeltons machen, das wäre dann so ein mittelweg,

Ich weiß, das das Singleton - Pattern nicht das gelbe vom Ei ist, aber es ist eine alternative bzw. eine Zwischenlösung,

Das Factory- Pattern arbeitet ja auch in die Richtung -> eine Instanz für die Helperklassen kann nur einmal erzeugt werden,

 

[Verjigorm]

Singleton ist hier doch garnicht interessant,
ich hab wenn überhaupt doch eh nur eine Instanz der Klasse

 

[Marco13]

Das ist wohl eine Sache, zu der man keine allgemeine Regel aufstellen kann - ausser der, die ich schon ein paarmal geopstet hatte:
- Fields sollten nur static sein, wenn sie es unbedingt sein müssen (und das müssen sie fast nie)
- Methoden sollten static sein, wenn man sie ohne Krämpfe static machen kann

Wenn du sagst, dass die Funktionen "nur irgendwas berechnen", kann man nicht sagen, ob sie static sein sollten oder nicht. Am Beispiel, das weiter oben angedeutet war: Eine Klasse "Kunde" hat Methoden, um sich Vor- und Nachnamen zu holen. Man könnte jetzt eine Methode anbieten

String getFullName() { return vor + nach; }

Wenn man aber stattdessen auf die Idee käme, sich dafür eine Utility-Klasse zu machen

class FullNameOfCustomerGetter
{
    public static String getFullName(Customer c) { return c.getVor() + c.getNach(); }
}

dann wäre das etwas, was IMHO in die Kategorie "Krampf" fallen würde...

Muss man wohl von Fall zu Fall enscheiden...

 

[Verjigorm]

Jo, das seh ich ein
aber meine Helper-Klassen haben z.B. nicht mal Klassenvariablen

 

[ms]

Jo, das seh ich ein
aber meine Helper-Klassen haben z.B. nicht mal Klassenvariablen

Ich finde es ist in Ordnung wenn du alles static machst.
Es gibt kein "zu viel" oder "zu wenig".
Schau dir mal java.lang.Math an, 100% statische Methoden und Felder.
Ich denke deine Klasse erfüllt analog dazu denselben Zweck.

ms

 

[Verjigorm]

yup, seh ich auch so, sind halt nen dutzend davon, die ich nach bestimmten "Kategorien" getrennt habe

 

[maki]

Hört sich wirklich danach an, als ob static reicht.

Genaues kann man erst sagen, wenn man den Code sieht

 

[PollerJava]

Noch ein Einwurf auch auf die Gefahr, dass er nicht zweckmäßig ist aber so weit ich weiß wäre da ja auch das Decorierer- Muster passend, da ich Objekte einhülle und nacheinandere Verhalten hinzufüge,
Das ist ja genau das, was Du da mit den Helper- Klassen versuchst.
Also ich persönlich würde mir eher das Designpattern-- Buch durchsehen, obs da eine NICHT- static Lösung gibt,
wenn man zu viel static macht, is ja gleich die Frage ob mans nicht in C macht (alles schnell ung global)

 

[Marco13]

aber meine Helper-Klassen haben z.B. nicht mal Klassenvariablen

Selbst das sagt ja nichts aus: Man kann praktisch ALLE Methoden static machen (wobei Konstruktoren und setter/getter hier eine Sonderrolle einnehmen). Ganz einfach indem das Objekt, auf dem sie arbeiten sollen, als Referenz übergeben wird. (Und - genau so macht das die JVM intern auch :wink: )

class Foo
{
    float a, b, result;
    void computeResult() { result = a + b; }
}

->

class Foo
{
    float a, b, result;
    static void computeResult(Foo foo) { foo.result = foo.a + foo.b; }
}

Das macht halt "manchmal" Sinn, aber "meistens" nicht - muss man sich halt überlegen....

 

[Verjigorm]

@ Marco13:

Sowas wie "float a, b, result;" existiert in meinen Klassen ja grade nicht, du macht WIEDER ein Beispiel damit ^^

 

[Marco13]

Die statische methode würde dann in der Helper-Klasse liegen, d.h "Foo" wäre eine deiner Klassen, die KEINE Helper-Klasse ist. (Und wenn du NUR Helper-Klassen hast, solltest du dir mal LISP ansehen :bae: )

 

[maki]

Verjigorm,

ohne Code ist das alles nur Spekulation, aber 3/4 static riecht verdächtig...

 

[Verjigorm]

Ich hab ja noch keinen Code, nur Modelle

Eine Methode soll z.B. folgendes machen:

Übergabewerte: Liste mit Int-Werten, JPanelbreite
Rückgabewerte: Liste mit Int-Werten

Die Funktion soll die Int-Werte der Liste auf die Breite des Panels transformieren.

Es wird die Spannweite der Int-Werte ermittelt (z.B. 0 bis 13)
dann wird die Panelbreite durch 13-0 geteilt und jedem Int-Wert so eine X-Koordinate in der Ebene zugeordnet.
Die neu erstelle Liste mit X-Koordinaten wird zurückgegeben.
Und die GUI-Klasse kann diese dann anzeigen.

Nix weltbewegendes, klingt für mich halt extrem nach Math-Prinzip über statische Methoden.

Und so Methoden gibt es aktuell 14 geplante, wobei das ständig mehr werden. Und die sind halt in Klassen zusammengefasst

Und die einzige Frage ist nun, ob ich das als statische Methode mache oder halt nicht

 

[maki]

Dafür würde ich keine static Methoden nehmen.

Lieber wrapper schreiben, vielleicht sogar das hier bereits erwähnte Decorator Muster.

 

[Gast]

Hallo,

auch auf die Gefahr hin mir den Zorn von diversen Personen abzubekommen. Aber wenn es darum geht "sauber" zu arbeiten sollte man auf static verzichten. Ich moechte hier nur ein kurzes Bsp. bzgl. der Helperklassen geben.

public class StringHelper {

    public static boolean machEt()...

}

public class Irgendwas {

    public void machirgendwas() {
        ...StringHelper.machEt()....
    }
}

Kurzanalyse:

Vorteile:
Das koennen die static Anhaenger sicher benennen...

Nachteile:
Man ist auf die Klasse StringHelper festgelegt, d.h. wenn man die mal Austauschen moechte gibt es Probleme.

Andere Moeglichkeit:

public interface StringHelper {

    public static boolean machEt();
}

@Component
public class StringHelperImpl implements StringHelper {

  public static boolean machEt()...

}

public class Irgendwas {

    @Autowired
    private StringHelper _stringHelper;

    private StringHelper getStringHelper() {
        return _stringHelper;
    }

    public void machirgendwas() {
        ...getStringHelper().machEt()....
    }
}

Vorteile:
- Man arbeitet gegen ein Interface und kann die Impl ohne Probleme austauschen.

Nachteil:
- Es muss ein DI-Container benutzt werden, z.B. Spring
- Es gibt ein Interface mehr .......


Gruesse

Gast

 

[SlaterB]

ein zumeist unnötiger Aufwand, der bei Bedarf kinderleicht nachgerüstet werden kann

 

[maki]

- Es muss ein DI-Container benutzt werden, z.B. Spring

Nicht wirklich, DI setzt keinen speziellen Container voraus
Spring ermöglicht es "nur", sehr einfach die Implementierungen auszutauschen, konfigueriert wird per XML.

Ansonsten stimme ich dir zu

 

[Gast von eben]

ein zumeist unnötiger Aufwand, der bei Bedarf kinderleicht nachgerüstet werden kann

Aufwand ist immer ein Feind von Qualitaet.

zusaetlicher Aufwand:

1. Erstellen des Interface

2. einfueges eines StringHelper Attributes

Zu 1.:

Dauer mit der richtigen IDE ca. 1 Minute

2. Template schreiben (2 Minuten) und in der Klasse aufrufen ca. 2 Sekunden.

Also, wegen letztendlich 2 Sekunden Mehraufwand pro Klasse wird auf ein bei groesseren Systemen wichtiges Architekturprinzip verzichtet....

Gruesse

Gast

 

[SlaterB]

Operation anklicken, rechte Maustaste, Open Declaration,
brauche ich zig mal am Tag,
wenn man dann nur zum Interface kommt und die Klasse manuell suchen muss, werde ich immer fast wahnsinnig
(Basisklase ginge natürlich auch)

edit:
dazu noch mehrere Hilfsklassen, Separation of Concerns wurde ja schon erwähnt
-> Klasse seitenweise gefüllt ohne echten Nutzwert,

dazu noch Hilfsklassenaufruf aus hunderten bis tausenden Datenobjekten heraus, wer soll die füllen?
alles ein heilloses Durcheinander wenn man so simple Dinge wie Math.max() braucht

selbstverständlich findet man sowas nicht in der Millionenfach-verwenden Java-API (also im einfachen Teil: Math, Collections, Arrays),
was wäre das für eine unvorstellbare Arbeitszeitvernichtung (ultimativ: System.out, statische Logger )


natürlich gibt es tolle Anwendungen dafür in wichtigen Stellen der 'groesseren Systeme',
für Allerweltshilfsklassen in Anfängerprogrammen ist das aber keine ernsthafte Alternative

 

[maki]

natürlich gibt es tolle Anwendungen dafür in wichtigen Stellen der 'groesseren Systeme',
für Allerweltshilfsklassen in Anfängerprogrammen ist das aber keine ernsthafte Alternative

Sehe ich nicht so, Java Anfänger (s/w)ollen doch OO lernen, und Helper waren eigentlich schon immer dynamisch, Utils eher nicht.

Speziell für Viewhelper würe ich keine rein statischen Lösung wählen.

 

[SlaterB]

worums genau geht muss man ja individuell festlegen,

> Helper waren eigentlich schon immer dynamisch, Utils eher nicht

mag sein und klingt ja schon anders als 'wenn es darum geht "sauber" zu arbeiten sollte man [generell] auf static verzichten'
was ja zurecht schon im Voraus den 'Zorn von diversen Personen' heraufbeschwor

 

[ms]

Andere Moeglichkeit:

public interface StringHelper {

    public static boolean machEt();
}

@Component
public class StringHelperImpl implements StringHelper {

  public static boolean machEt()...

}

Eine statische Methode in einem Interface deklarieren geht nicht.

ms

 

[SlaterB]

also auf 'Tippfehler, hier hast du fälschlicherweise static geschrieben' hinzuweisen wäre ja etwas banal, aber richtig
(ich hatte es nicht gesehen )

zu unterstellen, dass da jemand mit so viel Erklärung eine statische Operation in einem Interface deklarieren wollte,
ist aber fast schon ein größerer Fehler

 

[ms]

zu unterstellen, dass da jemand mit so viel Erklärung eine statische Operation in einem Interface deklarieren wollte,
ist aber fast schon ein größerer Fehler

Die Erklärung deutet aber leider nicht auf diesen Tippfehler hin.
Habs nur erwähnt damit jemand, der das hier in vielleicht 300 Jahren liest, nicht glaubt dass es so richtig ist.

ms

 

[quippy]

Ich hab ja noch keinen Code, nur Modelle

Eine Methode soll z.B. folgendes machen:

Übergabewerte: Liste mit Int-Werten, JPanelbreite
Rückgabewerte: Liste mit Int-Werten

Hier beginne ich zu grübeln. Wenn Du das JPanel mit übergibst (und nicht einen "int width"), klingt das eher nach einer Methode, welche in den JPanel-Ableitungsbaum gehört und damit nicht static sondern eine Service-Methode sein sollte.

Also eher etwas der Art

public abstract class CenterableJPanel extends JPanel // Keine Instanzen von diesem Ding hier!
{

   public void centerMeOn(int []ordinates)
   {
      //(....) Voodoo
   }
}

Ggf. bietet sich ein Interface an - dann hast Du aber wieder die Wahl der Implementierung... Eine statische Helper-Methode hätte ich erwartet, wenn die Übergabeparameter das Int-Array plus x,y,width,height des graphischen Objektes - also komplett Objekt-unabhängig wären.

Bei Math ist z.B. alles static, da man pro Methode nur einen Übergabewert hat, der nicht als klassifizierung des Math-Objektes dient. Bei einer Klasse "Winkel" mit trigonometrischen Funktionen wäre das aber wieder anders!

 

[Statischer Gast]

Stimmt natuerlich static in interface geht nicht.

Das zeigt wieder das Strg-C und Strg-V meist nicht zur Erhoehung der Codequalitaet beitraegt.... :wink:

 

[quippy]

auch auf die Gefahr hin mir den Zorn von diversen Personen abzubekommen. Aber wenn es darum geht "sauber" zu arbeiten sollte man auf static verzichten.

Das mit dieser Logik "static" per se nicht sauber ist, ist absoluter blödsinn.

Auch die Aussage

Also, wegen letztendlich 2 Sekunden Mehraufwand pro Klasse wird auf ein bei groesseren Systemen wichtiges Architekturprinzip verzichtet....

stimmt so nicht.

Selbst in Großprojekten sind statische Helper-Methoden mit eindeutigen Funktionen sinnvoll. Klar, daß ich die Implementierung nicht dynamisch austauschen kann, ist logisch - aber wenn man das will oder es zukünftig so sein könnte, darf man den static nicht verwenden. Zudem ist die statische Methode dann auch keine allgemeingültige Funktion mehr, wenn es bei unterschiedlichen Impls unterschiedliche Ergebnisse geben kann - damit gehört sie sowieso in ein Objekt und ist eine Instanzmethode.

Es wird z.B. niemand auf die Idee kommen, die Sinus-Funktion in Math auszutauschen. Das Ding berechnet einen Sinus - was sonst.

Eine Berechnungsmethode der folgenden Form

/*
 * Return the center x position on the screen coordinates for
 * an object of witdh oWidth
 */
public static int getCenterX(int screenMin, int screenMax, int oWidth)
{
   return (((screenMax - screenMin)>>1) - (oWidth>>1)) + screenMin;
}

ist ebenfalls so dermaßen allgemeingültig, daß sie so dastehen kann.

Wer OOP wirklich verstanden hat, kann die ganzen Designpattern-Bücher in einen wesentlich besseren Zusammenhang bringen und vor allem die Anwendungsgebiete klar erkennen. Keines dieser Pattern ist ein MUSS - aber sie helfen an den Stellen, für die sie gemacht wurden.

 

[Verjigorm]

Ich hab ja noch keinen Code, nur Modelle

Eine Methode soll z.B. folgendes machen:

Übergabewerte: Liste mit Int-Werten, JPanelbreite
Rückgabewerte: Liste mit Int-Werten

Hier beginne ich zu grübeln. Wenn Du das JPanel mit übergibst (und nicht einen "int width"), klingt das eher nach einer Methode, welche in den JPanel-Ableitungsbaum gehört und damit nicht static sondern eine Service-Methode sein sollte.

wo steht denn, dass ich das JPanel übergebe??
Nur die Breite des Panels, mehr nich

 

[byte]

Operation anklicken, rechte Maustaste, Open Declaration,
brauche ich zig mal am Tag

Machst du das echt so umständlich? Ich mache einfach STRG + Click. :roll:

wenn man dann nur zum Interface kommt und die Klasse manuell suchen muss, werde ich immer fast wahnsinnig
(Basisklase ginge natürlich auch)

Stimmt, da würde man wahnsinnig, wenns da nicht z.B. die Quick Type Hierarchy geben würde. Also einfach STRG + T drücken und Implementierung auswählen. Schon ist man da wo man hin will.

 

[SlaterB]

> einfach STRG + Click

ja, das wäre auch nicht schlecht,
kommt mir manchmal in die Quere bei 'Doppelklick zum Markieren + Strg-C zum Kopieren'

aber Rechtsklick, Linksklick ist auch schnell gemacht und braucht nur eine Hand, Gewöhnungssache sicherlich

> STRG + T drücken und Implementierung auswählen

das ist mir noch sehr ungewohnt

aber selbst wenn man das hat, ist es immer noch ein Schritt von direkter Sprung zu 'Subfenster, lesen, verstehen, zusätzlicher Klick zum Auswählen',
ziemlich bedeutend, finde ich, das kann man nicht klein rechnen

naja, wenn man nicht eh mehrere Implementierungen zur Auswahl hat,
dann fällt das Verstehen weg, dann muss man eh nur den einen Eintrag unter dem Interface auswählen,
das zeigt aber auch besonders deutlich, wie irrsinnig dieser zusätzliche unnötige Schritt im Gegensatz zum direkten Sprung ist

 

[byte]

> einfach STRG + Click

ja, das wäre auch nicht schlecht,
kommt mir manchmal in die Quere bei 'Doppelklick zum Markieren + Strg-C zum Kopieren'

aber Rechtsklick, Linksklick ist auch schnell gemacht und braucht nur eine Hand, Gewöhnungssache sicherlich

> STRG + T drücken und Implementierung auswählen

das ist mir noch sehr ungewohnt

aber selbst wenn man das hat, ist es immer noch ein Schritt von direkter Sprung zu 'Subfenster, lesen, verstehen, zusätzlicher Klick zum Auswählen',
ziemlich bedeutend, finde ich, das kann man nicht klein rechnen

naja, wenn man nicht eh mehrere Implementierungen zur Auswahl hat,
dann fällt das Verstehen weg, dann muss man eh nur den einen Eintrag unter dem Interface auswählen,
das zeigt aber auch besonders deutlich, wie irrsinnig dieser zusätzliche unnötige Schritt im Gegensatz zum direkten Sprung ist

Naja, aber aus Bequemlichkeit auf einen bedeutenden Grundsatz der OOP zu verzichten (Programmierung nach Interfaces), ist auch nicht der Weisheit letzter Schluß.
Und selbst wenn es nur eine Implementierung des Interface gibt, fallen einem genug Gründe dafür ein, trotzdem auf dem Interface zu arbeiten...

 

[SlaterB]

genauso unschlüssig ist es, aus reinem Selbstzweck sinnlos einen bedeutenden Grundsatz einzusetzen

es macht keinen Sinn, ganz simpel,

um das Quadrat von 5 auszurechen darf man wirklich
int x = 5*5; rechnen,
und damit auf den bedeutendsten Grundsatz überhaupt, den Objekten selber, verzichten


wenn es in einer bestimmten Situation fachlich absolut egal ist, ob man statisch einsetzt oder nicht,
und das einzige Pro-Argument 'nicht-statisch ist aber schöner OOP' ist,
dann darf ja wohl das Contra-Argument 'schöner, aber macht einen Haufen Arbeit' genauso stehen bleiben

edit:
'Programmierung nach Interfaces' ist auch für sich kein Grundsatz den man überall einsetzt,
etwa bei allen Datenklassen, bei JFrames usw,
kein Mensch hat doch wohl ein ganzes Programm nur aus Interfacen?,
insbesondere wieder noch weniger in einfachen Anfängerprogrammen

wenn man das so sieht, dann hat ja static tatsächlich generell jede Berechtigung verloren,
aber das wäre ja noch ein Schritt weiter als ich das bisher hier gesehen habe,
für ALLE Klassen in einem Projekt..

 

[Guest]

> einfach STRG + Click

ja, das wäre auch nicht schlecht,
kommt mir manchmal in die Quere bei 'Doppelklick zum Markieren + Strg-C zum Kopieren'

aber Rechtsklick, Linksklick ist auch schnell gemacht und braucht nur eine Hand, Gewöhnungssache sicherlich

> STRG + T drücken und Implementierung auswählen

das ist mir noch sehr ungewohnt

(..)

also ich mach das einfach mit F3