Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
Wie eine Methode/Funktion aus einer Klasse mit Constructor aufrufen?
auf, aber values() ist static, weshalb auch der obige Code von IntelliJ Gelb markiert wird. Ich kann aber nicht einfach
Java:
Load.values();
schreiben, da sonst der Constructor nicht mit aufgerufen wird und in diesem Constructor werden wichtige Elemente zu einer ArrayList hinzugefügt. Jedoch sehe ich es auch als unnötig, immer die Elemente zu einer ArrayList hinzuzufügen, wenn new Load.values() aufgerufen wird, denn das Hinzufügen zur ArrayList muss ja nur einmal geschehen. Meine Frage: Wie kann ich die Funktion values() mit dem Constructor aufrufen?
Würde ich nicht damit außerdem jedes Mal ein neues Objekt erstellen?:
Java:
Load load = new Load();
load.values(); // Wird Gelb markiert, weil er auf values über die Referenz "Load"(.values()) zugreifen möchte
Kannst Du das einmal konkret zeigen? Was genau versuchst Du da? Das hört sich erst einmal sehr dubios an, als ob Du da etwas mischst, das so keinen Sinn macht.
Wenn in der static Methode values() irgendwas initialisiert sein muss, dann kannst Du das ggf. im Aufruf machen so es noch nicht erfolgt ist. Also wie bei dem Singleton Pattern.
Oder Du hast in values etwas, das halt eine Instanz benötigt und die Frage, die dann sofort im Raum steht: Wieso ist es dann static?
Generell solltest Du objektorientiert arbeiten und static bricht dies in der Regel. Die einzigen Dinge, die static sein dürfen, sollten bei Dir sein:
die main Methode
Konstanten
Alle weiteren Dinge sollten NICHT static sein. Auch das Singleton Pattern ist extrem umstritten und sollte vermieden werden! (Über DI / IoC Ansätze bekommt man zwar auch etwas, das ähnlich ist / sein kann, aber ohne die vielen Probleme, die das eigentliche Singleton Pattern mit sich bringt)
Erstelle die Instanz nur einmal und verwende sie überall dort, wo du sie benötigst.
Falls eine andere Instanz sie benötigt, dann übergebe sie z. B. im Konstruktor oder über Setter.
Java:
Load load = new Load(); // Klassennamen sollten Substantive sein! => z. B. Loader
load.values();
OtherClass oc = new OtherClass(load); // andere Instanz, die den Loader benötigt
// oder z. B.
oc.setLoader(load);
// oder z. B.
oc.doSomethingWithAList(load.getList());
Die Antwort ist allerdings, sagen wir mal, etwas "aus dem Fenster gelehnt", ohne genaueres über dein Vorhaben zu wissen.
Ansonsten gilt in den meisten Fällen, was zu "static" im Beitrag darüber steht.
Erstelle die Instanz nur einmal und verwende sie überall dort, wo du sie benötigst.
Falls eine andere Instanz sie benötigt, dann übergebe sie z. B. im Konstruktor oder über Setter.
Java:
Load load = new Load(); // Klassennamen sollten Substantive sein! => z. B. Loader
load.values();
OtherClass oc = new OtherClass(load); // andere Instanz, die den Loader benötigt
// oder z. B.
oc.setLoader(load);
// oder z. B.
oc.doSomethingWithAList(load.getList());
Die Antwort ist allerdings, sagen wir mal, etwas "aus dem Fenster gelehnt", ohne genaueres über dein Vorhaben zu wissen.
Ansonsten gilt in den meisten Fällen, was zu "static" im Beitrag darüber steht.
Also kann ich dieses Access static 'Loader.values()' via class 'Loader' reference' ignorieren?
Wenn ich dann 4 Klassen habe, von denen ich Methoden aufrufen muss, ist der folgende Code also nicht falsch?:
Java:
Loader loader = new Loader();
Zweite zweite = new Zweite();
Dritte dritte = new Dritte();
Vierte vierte = new Vierte();
// ...
void funktion() {
loader.XY();
zweite.XY();
dritte.XY();
vierte.XY();
}
Kommt drauf an. Wenn die vier deklarierten Variablen Instanzvariablen der Klasse mit der Methode funktion() sind (Methodenamen sollten wiederum Verben sein), dann ist der Code (vielleicht) richtig. Ansonsten würde die Methode funktion() die Variablen nicht kennen und der Code wäre falsch.
Aber ja, in der Regel werden Instanzen von Klassen erstellt und mit diesen Instanzen wird gearbeitet, z. B. indem Methoden darauf aufgerufen werden.
Was du mit deiner ersten Aussage meinst, ist mir nicht ganz klar. Vielleicht solltest du zeigen, wie die Klasse aussieht, um das verstehen oder verbessern zu können.
Kommt drauf an. Wenn die vier deklarierten Variablen Instanzvariablen der Klasse mit der Methode funktion() sind (Methodenamen sollten wiederum Verben sein), dann ist der Code (vielleicht) richtig. Ansonsten würde die Methode funktion() die Variablen nicht kennen und der Code wäre falsch.
Aber ja, in der Regel werden Instanzen von Klassen erstellt und mit diesen Instanzen wird gearbeitet, z. B. indem Methoden darauf aufgerufen werden.
Was du mit deiner ersten Aussage meinst, ist mir nicht ganz klar. Vielleicht solltest du zeigen, wie die Klasse aussieht, um das verstehen oder verbessern zu können.
Was ist mit der ersten Aussage meine:
Wenn ich über diese gelbmarkierten Zeilen mit der Maus hover, dann erscheint der Text Access static 'Loader.values()' via class 'Loader' reference':
Da es nur eine Warnung ist, könntest Du es ignorieren. Aber die Warnung hat einen guten Grund: Klassenmethoden werden über die Klasse aufgerufen, damit das auch im Aufruf direkt sichtbar ist.
Statt dem
Java:
Load load = new Load();
load.values();
sollte es einfach ein:
Java:
Load load = new Load();
Load.values();
sein.
Also statt der Instanzvariable einfach die Klasse angeben!
Die Klasse hat doch alles static. Wozu willst Du da überhaupt jemals einen Konstruktor aufrufen?
Und warum ist da alles static? Wenn Du einen Loader brauchst, dann erstellst Du einen. FXMLLoader ist auch so ein Loader. Da erstellst Du eine Instanz, wenn Du es brauchst.
Die Klasse hat doch alles static. Wozu willst Du da überhaupt jemals einen Konstruktor aufrufen?
Und warum ist da alles static? Wenn Du einen Loader brauchst, dann erstellst Du einen. FXMLLoader ist auch so ein Loader. Da erstellst Du eine Instanz, wenn Du es brauchst.
Nein, du rufst einfach die statischen Methoden über den Klassennamen auf. Den Konstruktor brauchst du nicht.
Es gibt manchmal Gründe, Variablen oder Methoden statisch zu machen, wie hier im JavaFX Framework. Man sollte allerdings schon wissen, warum man es tut und was es bewirkt. Ansonsten lass dich nicht verwirren, die oben genannten Tipps zu "static" gelten schon i.d.R., insbesonders für Einsteiger und vermutlich auch für den Rest deines Programms.
Allerdings bin ich trotzdem etwas verwirrt. Eine schnelle Suche in der Doku von JavaFX hat keine Klasse "Loader" gefunden, allenfalls "FXMLLoader". Woher kommt diese Klasse denn nun? Vielleicht hab ich sie allerdings auch übersehen...
Moment, das ist doch eine selbst geschriebene Klasse. Und da ist es egal, ob man es ein JavaFX einsetzen will oder ob man kein JavaFX nutzt.
Die Klasse ist aus meiner Sicht ein Beispiel, wie man etwas auf keinen Fall machen sollt! Du hast da sehr viel State drin, also Daten. Wie willst Du sowas vernünftig testen? Ohne da irgend wem zu nahe treten zu wollen: So ist die Klasse einfach Müll.
Bitte schau Dir an, wie man Instanzen erzeugt und verwendet. Der Code zeigt auch an anderen Stellen, dass es da massiv Defizite gibt, denn es macht den Eindruck, dass sonst sehr viel bei Dir Singeltons sind. Main und ControllerRepository fallen da direkt ins Auge.
Ich weiss nicht, was Du da an Programm schreibst, aber ich befürchte, dass Du mit dem Ansatz noch in starke Probleme rennen wirst.
Allerdings bin ich trotzdem etwas verwirrt. Eine schnelle Suche in der Doku von JavaFX hat keine Klasse "Loader" gefunden, allenfalls "FXMLLoader". Woher kommt diese Klasse denn nun? Vielleicht hab ich sie allerdings auch übersehen...
Das ist eine von ihm erstellte Klasse. Du wirst in JavaFX keine Klassen finden, die rein statisch sind und dabei einen State haben. Du magst Utility-Klassen finden, aber nie so etwas.
Wollen wir einfach einmal ein paar Dinge etwas erläutern, damit klar ist, warum man gewisse Dinge nicht machen sollte. Das ist ein hoch komplexes Thema und da kommen dann auch so Themen mit rein wie: Warum Interfaces und so...
Das Ganze halten wir sehr visuell, d.h. ich nehme ein anschauliches Beispiel. Da lässt sich nicht alles 1:1 übertragen, aber bestimmt hilft es.
Das grobe Bild:
Nehmen wir einfach einmal eine Fabrik. In der Fabrik sind diverse Maschinen und jede Maschine besteht wieder aus irgendwelchen Bauteilen.
Wenn man sich das etwas anschaut, dann erkennt man mehrere Dinge.
Es gibt sowas wie Ebenen: Ganz oben ist die Fabrik. Das ist sozusagen das, was alles umschliesst. In der Fabrik gibt es dann diverse Maschinen. Die Fabrik weiss natürlich, was für Maschinen in der Fabrik sind. Jede Maschine besteht aus Bauteilen. Also z.B. Zahnräder, Schrauben, .... Die Fabrik hat keine Ahnung, was für Schrauben in den Maschinen sind - wenn man das also etwas abstrahiert, dann interessiert eine Ebene immer maximal die direkt anliegende - es wird aber nie eine Ebene übersprungen.
Es gibt Schnittstellen. Eine Maschine bekommt einen Input, hat einen Output und es gibt Steuermöglichkeiten.
Man erkennt hier, dass es sehr sinnvoll ist, die Schnittstelle festzulegen. Dann kann ich Teil gegen einen anderen austauschen, das die gleiche Schnittstelle hat. Das kann also sein, dass man in einer Maschine eine Schraube durch eine andere austauscht. Oder eine ganze Maschine durch eine andere.
Abhängigkeiten sind etwas ganz schlimmes. Wenn die Maschine eine feste Abhängigkeit hat zu der Fabrik, dann kannst Du die Maschine nicht in einer anderen Fabrik verwenden. Oder wenn es eine feste Abhängigkeit zu einer anderen Maschine gibt, dann ist die Einsatzmöglichkeit sehr begrenzt. Machen wir da mal ein Bespiel:
M1 ist eine Maschine, die Stahlrohre herstellt.
M2 ist eine Maschine, die Stahlrohre annimmt um diese zu Fahrradrahmen zusammen zu fügen / schweissen.
Wenn Du bei der Herstellung von M1 und M2 die Abhängigkeit fest einbaust, also M1 gibt Stahlrohre direkt an M2 und M2 nimmt die auch immer direkt von M1, dann hast Du ein Problem. Wenn Du jetzt aus Stahlrohren ein Sicherheitskäfig für ein Ralley-Fahrzeug bauen willst, dann kannst Du M1 nicht verwenden, denn M1 würde die Stahlrohre ja an M2 geben und du hast keine Chance, das an eine andere Maschine M3 anzuschließen.
Und wenn Du nun Rohre aus einer anderen Quelle als M1 verarbeiten willst: Mit M2 ist das auch nicht möglich.
Wenn man jetzt mehrere Fabriken betrachtet, dann hat man da Abhängigkeiten zwischen den Fabriken. Aber nie zu einer konkreten Maschine. Wenn ich als Fabrik2 von Fabrik1 Fahrradrahmen haben will, dann ist es mir egal, ob das eine Maschine M2 macht oder irgend eine andere Maschine. Mir ist nur wichtig: Fabrik1 muss liefern. Und Abhängigkeiten gehen nur in eine Richtung (so möglich). Also Fabrik1 liefert Fahrradrahmen an Fabrik2 .... Fabrik2 liefert aber nichts an Fabrik1. (Das ist ein etwas problematischer Vergleich. Hier geht es mehr darum, wer etwas anspricht. Also Fabrik1 liefert etwas an Fabrik2, aber dabei kann etwas zurück kommen. Also es werden Fahrradrahmen geliefert und ein Koffer mit Geld wird dann auf der Rückfahrt mitgenommen.)
Was bedeutet das für einen Software Entwickler:
Natürlich machen wir nichts rein statisch. Das würde ja bedeuten, dass man nur genau eine Maschine hätte. Aber man will vielleicht mehrere haben...
Wie achten auf Ebenen und auf Module. Wenn es also möglich ist, machen wir Module (was dann die Fabriken wären). Diese sind relativ abgeschlossen und haben auch klare Ein- und Ausgänge sowie Steuerungsmöglichkeiten. Und wie bei Klassen Internas gekapselt werden, ist das bei Modulen ähnlich.
Bei eine JavaFX Applikation kann man das dann ähnlich aufbauen:
Du hast eine Applikation, die alles Kapselt. Die weiss also, was für Komponenten es sonst gibt.
Die Applikation kann die Komponenten miteinander verbinden. Die Komponenten kennen also nicht die Applikation oder so.
Wenn eine Komponente Abhängigkeiten hat zu anderen Komponenten, dann kann das so aussehen:
M1 liefert Stahlrohre an M2. M1 ist also ein Producer und M2 ein Consumer (von Stahlrohren)
M1 braucht aber natürlich den Stahl also ist auch ein Consumer<Stahl>
Damit M1 funktioniert, braucht es aber einen Producer<Stahl> und einen Consumer<Stahlrohr>
Das wäre bei M1 also etwas wie:
Java:
M1 liefert Stahlrohre an M2. M1 ist also ein Producer und M2 ein Consumer
(von Stahlrohren)
M1 braucht aber natürlich den Stahl also ist auch ein Consumer<Stahl>
Damit M1 funktioniert, braucht es aber einen Producer<Stahl> und einen Consumer<Stahlrohr>
public class M1 implements Producer<Stahlrohr>, Consumer<Stahl> {
public M1(Producer<Stahl> stahlLieferant, Consumer<Stahlrohr> stahlrohrAbhnehmer) {
// ...
}
}
Das würde beide Richtungen abdecken. Braucht man aber oft nicht. In der Regel ist eine Seite aktiv und die andere passiv. Das Stahl kommt aus dem Stahllager und die Maschine M1 kann es anfordern. Und die Maschine M1 gibt es aktiv an die Maschine M2.
Wenn M2 die Stahlrohre bekommt, dann ist es egal, woher es kommt. Das muss die Maschine ja nicht wissen.
Ein weiterer, wichtiger Punkt: Wenn die Interfaces Funktional sind, dann braucht man dieses implements nicht. Dann hat man einfach entsprechende Methoden oder man gibt es als Lambda Expression an.
Beispiel:
Das Interface Consumer<Stahlrohr> hat eine Methode verwende(Stahlrohr)
M2 hat eine Methode, die heisst produziereFahrradrahmen(Stahlrohr) und implementiert nicht Consumer<Stahlrohr>.
Das Consumer<Stahlrohr> kann dann bei einer Instanz m2 angegeben werden als: m2::produziereFahrradrahmen ==> Methodenreferenz r -> m2.produziereFahrradrahmen(r) ==> Lambda Expression
Das wäre so eine schnelle Übersicht, was da so denkbar wäre und wie so ein Aufbau sein sollte. So kurz lässt sich das aber nicht wirklich gut erläutern. Da gibt es viele - teilweise sehr umfangreiche - Bücher zu. Aber für einen ersten Einblick hat es hoffentlich gereicht. Und ich hoffe, dass ich beim so runter schreiben nicht groß Tippfehler und so eingebaut habe.
Wollen wir einfach einmal ein paar Dinge etwas erläutern, damit klar ist, warum man gewisse Dinge nicht machen sollte. Das ist ein hoch komplexes Thema und da kommen dann auch so Themen mit rein wie: Warum Interfaces und so...
Das Ganze halten wir sehr visuell, d.h. ich nehme ein anschauliches Beispiel. Da lässt sich nicht alles 1:1 übertragen, aber bestimmt hilft es.
Das grobe Bild:
Nehmen wir einfach einmal eine Fabrik. In der Fabrik sind diverse Maschinen und jede Maschine besteht wieder aus irgendwelchen Bauteilen.
Wenn man sich das etwas anschaut, dann erkennt man mehrere Dinge.
Es gibt sowas wie Ebenen: Ganz oben ist die Fabrik. Das ist sozusagen das, was alles umschliesst. In der Fabrik gibt es dann diverse Maschinen. Die Fabrik weiss natürlich, was für Maschinen in der Fabrik sind. Jede Maschine besteht aus Bauteilen. Also z.B. Zahnräder, Schrauben, .... Die Fabrik hat keine Ahnung, was für Schrauben in den Maschinen sind - wenn man das also etwas abstrahiert, dann interessiert eine Ebene immer maximal die direkt anliegende - es wird aber nie eine Ebene übersprungen.
Es gibt Schnittstellen. Eine Maschine bekommt einen Input, hat einen Output und es gibt Steuermöglichkeiten.
Man erkennt hier, dass es sehr sinnvoll ist, die Schnittstelle festzulegen. Dann kann ich Teil gegen einen anderen austauschen, das die gleiche Schnittstelle hat. Das kann also sein, dass man in einer Maschine eine Schraube durch eine andere austauscht. Oder eine ganze Maschine durch eine andere.
Abhängigkeiten sind etwas ganz schlimmes. Wenn die Maschine eine feste Abhängigkeit hat zu der Fabrik, dann kannst Du die Maschine nicht in einer anderen Fabrik verwenden. Oder wenn es eine feste Abhängigkeit zu einer anderen Maschine gibt, dann ist die Einsatzmöglichkeit sehr begrenzt. Machen wir da mal ein Bespiel:
M1 ist eine Maschine, die Stahlrohre herstellt.
M2 ist eine Maschine, die Stahlrohre annimmt um diese zu Fahrradrahmen zusammen zu fügen / schweissen.
Wenn Du bei der Herstellung von M1 und M2 die Abhängigkeit fest einbaust, also M1 gibt Stahlrohre direkt an M2 und M2 nimmt die auch immer direkt von M1, dann hast Du ein Problem. Wenn Du jetzt aus Stahlrohren ein Sicherheitskäfig für ein Ralley-Fahrzeug bauen willst, dann kannst Du M1 nicht verwenden, denn M1 würde die Stahlrohre ja an M2 geben und du hast keine Chance, das an eine andere Maschine M3 anzuschließen.
Und wenn Du nun Rohre aus einer anderen Quelle als M1 verarbeiten willst: Mit M2 ist das auch nicht möglich.
Wenn man jetzt mehrere Fabriken betrachtet, dann hat man da Abhängigkeiten zwischen den Fabriken. Aber nie zu einer konkreten Maschine. Wenn ich als Fabrik2 von Fabrik1 Fahrradrahmen haben will, dann ist es mir egal, ob das eine Maschine M2 macht oder irgend eine andere Maschine. Mir ist nur wichtig: Fabrik1 muss liefern. Und Abhängigkeiten gehen nur in eine Richtung (so möglich). Also Fabrik1 liefert Fahrradrahmen an Fabrik2 .... Fabrik2 liefert aber nichts an Fabrik1. (Das ist ein etwas problematischer Vergleich. Hier geht es mehr darum, wer etwas anspricht. Also Fabrik1 liefert etwas an Fabrik2, aber dabei kann etwas zurück kommen. Also es werden Fahrradrahmen geliefert und ein Koffer mit Geld wird dann auf der Rückfahrt mitgenommen.)
Was bedeutet das für einen Software Entwickler:
Natürlich machen wir nichts rein statisch. Das würde ja bedeuten, dass man nur genau eine Maschine hätte. Aber man will vielleicht mehrere haben...
Wie achten auf Ebenen und auf Module. Wenn es also möglich ist, machen wir Module (was dann die Fabriken wären). Diese sind relativ abgeschlossen und haben auch klare Ein- und Ausgänge sowie Steuerungsmöglichkeiten. Und wie bei Klassen Internas gekapselt werden, ist das bei Modulen ähnlich.
Bei eine JavaFX Applikation kann man das dann ähnlich aufbauen:
Du hast eine Applikation, die alles Kapselt. Die weiss also, was für Komponenten es sonst gibt.
Die Applikation kann die Komponenten miteinander verbinden. Die Komponenten kennen also nicht die Applikation oder so.
Wenn eine Komponente Abhängigkeiten hat zu anderen Komponenten, dann kann das so aussehen:
M1 liefert Stahlrohre an M2. M1 ist also ein Producer und M2 ein Consumer (von Stahlrohren)
M1 braucht aber natürlich den Stahl also ist auch ein Consumer<Stahl>
Damit M1 funktioniert, braucht es aber einen Producer<Stahl> und einen Consumer<Stahlrohr>
Das wäre bei M1 also etwas wie:
Java:
M1 liefert Stahlrohre an M2. M1 ist also ein Producer und M2 ein Consumer
(von Stahlrohren)
M1 braucht aber natürlich den Stahl also ist auch ein Consumer<Stahl>
Damit M1 funktioniert, braucht es aber einen Producer<Stahl> und einen Consumer<Stahlrohr>
public class M1 implements Producer<Stahlrohr>, Consumer<Stahl> {
public M1(Producer<Stahl> stahlLieferant, Consumer<Stahlrohr> stahlrohrAbhnehmer) {
// ...
}
}
Das würde beide Richtungen abdecken. Braucht man aber oft nicht. In der Regel ist eine Seite aktiv und die andere passiv. Das Stahl kommt aus dem Stahllager und die Maschine M1 kann es anfordern. Und die Maschine M1 gibt es aktiv an die Maschine M2.
Wenn M2 die Stahlrohre bekommt, dann ist es egal, woher es kommt. Das muss die Maschine ja nicht wissen.
Ein weiterer, wichtiger Punkt: Wenn die Interfaces Funktional sind, dann braucht man dieses implements nicht. Dann hat man einfach entsprechende Methoden oder man gibt es als Lambda Expression an.
Beispiel:
Das Interface Consumer<Stahlrohr> hat eine Methode verwende(Stahlrohr)
M2 hat eine Methode, die heisst produziereFahrradrahmen(Stahlrohr) und implementiert nicht Consumer<Stahlrohr>.
Das Consumer<Stahlrohr> kann dann bei einer Instanz m2 angegeben werden als: m2::produziereFahrradrahmen ==> Methodenreferenz r -> m2.produziereFahrradrahmen(r) ==> Lambda Expression
Das wäre so eine schnelle Übersicht, was da so denkbar wäre und wie so ein Aufbau sein sollte. So kurz lässt sich das aber nicht wirklich gut erläutern. Da gibt es viele - teilweise sehr umfangreiche - Bücher zu. Aber für einen ersten Einblick hat es hoffentlich gereicht. Und ich hoffe, dass ich beim so runter schreiben nicht groß Tippfehler und so eingebaut habe.
@KonradN hat ja zum Glück schon so einen langen Salm geschrieben, das wollte ich auch gerade tun.
Du solltest dir das Thema Objektorientierung dringend verinnerlichen. Wenn man es mal verstanden hat ist es so natürlich wie der aufrechte Gang, aber es dauert doch ein wenig die Denkweise so richtig zu übernehmen.
Grundsätzlich sind Objekte erstmal Dinge, die eine gewisse Eigenständigkeit haben und (idealerweise exakt eine einzige) Aufgabe erfüllen.
Nimm z.B. mal ein beliebiges Programm, das mit einem Server kommunizieren soll. Dann könntest du z.B. eine Klasse "ServerConnector" haben, die nach außen hin zwei Methoden bereitstellt, einmal um Daten zu senden und einmal um empfangene Daten abzuholen, von außen ganz einfach.
Der innere Aufbau dieser Klasse kann jetzt beliebig kompliziert sein. Es kann z.B. erforderlich sein, sich in bestimmten Zeitintervallen beim Server melden zu müssen damit der Server weiß, daß der Client noch lebt. Ansonsten nimmt der Server an, das Programm wurde beendet und der Server unterbricht die Verbindung. Die Daten können auch noch verschlüsselt werden, bevor sie an den Server rausgehen, usw.
Darum würde sich die Klasse ServerConnector z.B. kümmern.
Zeigt sehr schön, warum Objektorientierung so geil ist: von außen recht einfach zu benutzen, innen passieren wunderliche Dinge in denen man von außen auch bitte nicht herumrühren soll, deshalb auch der ganze Kram mit Sichtbarkeitsmodifizierern wie private, public, usw. Es wäre doch auch zu dumm, wenn man den Kryptoschlüssel im Klartext irgendwo in eine Datei ablegen könnte, nur weil jemand meint das wäre eine einfache Lösung für sein Problem und noch sicher genug. Ein 'private' verhindert dies.
Und um jetzt zu deiner Frage zurückzukommen: Ein Objekt zu erstellen (nichts anderes machst du nämlich, wenn du den Konstruktor aufrufst) nur um eine einzige Methode aufzurufen, läuft dem Sinn eines Objekts zuwider. Es ist gerade umgekehrt: Wenn du eine Methode statisch machst, existiert diese Methode immer, und es wird eben nicht jedesmal ein neues Objekt erzeugt.
Wenn du häufig Methoden über den Konstruktor aufrufen willst ist das ein gutes Anzeichen dafür, daß du da nochmal einiges überdenken (und evt. lesen/lernen) solltest.
