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.
hab mal ne grundlegende Frage. Warum soll man keine Klassen erstellen, die dann nur als Methodenlieferanten dienen. Dies macht manches doch sehr übersichtlich. Für eine kurze Erklärung wäre ich sehr dankbar.
Gruß Thorsten
Nun, das meine ich nicht. Mir ist nicht klar, warum ich bei einem Projekt, in dem ich zig Methoden brauche, nicht zusätzlich Klassen erstellen soll, welche nur dazu dienen, eine Methode zur Verfügung zu stellen und einen Wert oder sonstiges zurückgeben. Vor allem wenn die Methoden sehr umfangreich sind, finde ich, dass dies dann sehr übersichtlich ist, wenn nicht alles in einer Klasse steht.
Wenn du allgemeingültige statische Methoden hast, wie z.B. eine Methode zum kopieren von Dateien, dann ist es imho schon sinnvoll sie in einer Klasse "HelperMethods" zu sammeln, falls sie sich sonst nirgendwo sinnvoll unterbringen lassen.
OK, erst mal dankeschön.
Aber nochmal gefragt, warum denn keine allgemeingültigen, nicht statische Methoden in seperaten Klassen unterbringen??
Was spricht den dagegen?
Soory, ist vielleicht ne dumme Frage, aber ich bin Anfänger und weiß es nicht und ich denke dies ist schon wichtig um sich einen ordentlichen Stil anzugewöhnen.
Mir ist nicht klar, warum ich bei einem Projekt, in dem ich zig Methoden brauche, nicht zusätzlich Klassen erstellen soll, welche nur dazu dienen, eine Methode zur Verfügung zu stellen und einen Wert oder sonstiges zurückgeben. Vor allem wenn die Methoden sehr umfangreich sind, finde ich, dass dies dann sehr übersichtlich ist, wenn nicht alles in einer Klasse steht.
Vielleicht tust du mal besser Butter bei die Fische und bringst ein Beispiel, WAS für Methoden du in WELCHE Klassen packen willst. Das wird aus deinem Text nämlich nicht ersichtlich.
Meiner Meinung nach ist es sinnvoll, Methoden (auch wenn sie statisch sind) die ähnliches machen zu einer Klasse zusammenzufügen, sobald die darin enthaltenen Methoden mehr als einmal während des Programmablaufs benötigt werden.
Vielleicht tust du mal besser Butter bei die Fische und bringst ein Beispiel, WAS für Methoden du in WELCHE Klassen packen willst. Das wird aus deinem Text nämlich nicht ersichtlich.
Sorry, es geht mir nicht um spezielle Methoden, ich habe auch kein Beispiel zur Hand. Es geht mir vielmehr ums Prinzip.
Also nochmal. Ich erstelle ein Projekt, welches ca. 10 Klassen enthält, bzw. aus 10 Klassen besteht. Es handelt sich dabei um ein Programm, welches mittels einer GUI bedient wird. Im Hintergrund werden Datenbanken abgefragt und die Datensätze
danach verarbeitet. Dabei findet eine Sortierung statt, u.a. werden String anhand ihres Aufbaus, bzw Inhalts mit zig Schleifen bearbeitet.
So, dass wars. Nun wurde ich darauf aufmerksam gemacht, das es nicht sinvoll ist, z.B. eine seperate Klasse zu erstellen, welche eine Mehode enthält die einen String übergeben bekommt und diesen verarbeitet, als Ergebnis einen String zurück liefert.
Also einfach dargestellt z.B. sowas :
Code:
public class Hauptklasse{
String s = "blablabla, blablabla";
public static void main(String[]args){
NeueKlasse neu = new NeueKlasse();
String h = neu.verarbeite(s);
}
Das solltest du den fragen, der dir den Floh ins Ohr gesetzt hat. Man kann eben nicht verallgemeinernd sagen, dass irgendwass immer unssinnig oder sinnig ist. Darum meine Frage nach konkreten Beispielen. Wenn eine Methode nicht mit Instanzdaten arbeitet, ist schonmal was faul im Staate Dänemark, nur kann ich das allein an der Signatur nicht unbedingt erkennen und damit die Frage auch nicht definitiv und immer richtig beantworten
Vielleicht tust du mal besser Butter bei die Fische und bringst ein Beispiel, WAS für Methoden du in WELCHE Klassen packen willst. Das wird aus deinem Text nämlich nicht ersichtlich.
Sorry, es geht mir nicht um spezielle Methoden, ich habe auch kein Beispiel zur Hand. Es geht mir vielmehr ums Prinzip.
Also nochmal. Ich erstelle ein Projekt, welches ca. 10 Klassen enthält, bzw. aus 10 Klassen besteht. Es handelt sich dabei um ein Programm, welches mittels einer GUI bedient wird. Im Hintergrund werden Datenbanken abgefragt und die Datensätze
danach verarbeitet. Dabei findet eine Sortierung statt, u.a. werden String anhand ihres Aufbaus, bzw Inhalts mit zig Schleifen bearbeitet.
So, dass wars. Nun wurde ich darauf aufmerksam gemacht, das es nicht sinvoll ist, z.B. eine seperate Klasse zu erstellen, welche eine Mehode enthält die einen String übergeben bekommt und diesen verarbeitet, als Ergebnis einen String zurück liefert.
Also einfach dargestellt z.B. sowas :
Code:
public class Hauptklasse{
String s = "blablabla, blablabla";
public static void main(String[]args){
NeueKlasse neu = new NeueKlasse();
String h = neu.verarbeite(s);
}
Welchen Sinn macht es eine Klasse zu instanziieren die dann keinen Zustand in irgend einer Weise hat? Wenn du nur Methoden willst dann kannst du auch statische Methoden nehmen. Aber du solltest vielleicht mal dein Programm OO analysieren und gucken ob die wirklich Methoden hast du zu keinem Objekt gehören.
Welchen Sinn macht es eine Klasse zu instanziieren die dann keinen Zustand in irgend einer Weise hat? Wenn du nur Methoden willst dann kannst du auch statische Methoden nehmen. Aber du solltest vielleicht mal dein Programm OO analysieren und gucken ob die wirklich Methoden hast du zu keinem Objekt gehören.
Nun ja, gerade hier im Forum wird ja oft die Meinung vertreten, dass statics mindestens dem OP-Gedanken widersprechen, wenn nicht gar Teufelswerk sind :wink:
Aber ernsthaft: um bei einer späteren Erweiterung, bei der man feststellt, dass die ehemals allgemeingültigen Methoden eben doch von irgendeinem Kontext anhängen (z.B. vom angemeldeten Benutzer in einer Multi-User-Umgebung), dann muss man mit einigem Aufwand die statics umbauen. Dem kann man vorbeugen, indem gleich Instanzmethode vorsieht.
Offenbar waren selbst die Designer der Java-Standardbibliotheken sich hier nicht immer ganz einig, oder warum sind in java.lang.System alle Methoden statisch, während man sich von java.lang.Runtime mit Runtime#getRuntime erst eine Instanz besorgen muss (wobei in der API-Doku ganz klar ausgesagt wird, dass es nur eine Runtime-Instanz pro Applikation geben kann)?
Offenbar waren selbst die Designer der Java-Standardbibliotheken sich hier nicht immer ganz einig, oder warum sind in java.lang.System alle Methoden statisch, während man sich von java.lang.Runtime mit Runtime#getRuntime erst eine Instanz besorgen muss (wobei in der API-Doku ganz klar ausgesagt wird, dass es nur eine Runtime-Instanz pro Applikation geben kann)?
Problem ist grundsätzlich, dass Java selbst an vielen Stellen zeigt, wie man es nicht machen sollte. Daran sollte man sich nich tunbedingt ein Besipiel nehmen, was aber umso schwerer ist, je weniger erfahren man ist (woher soll mans sonst wissen?).
Klar, das ist schon richtig, aber warum gibt es dann nicht auch System#getSystem und Instanzmethoden von System?
Aber wie Al schon sagte: die Java-Bibliotheken sind sicher nicht immer als Beispiel für perfektes Design gut (zumal sie natürlich kaum grundlegend verändert werden könnten, weil sie auch mit altem Code kompatibel bleiben müssen)
Sagen wir mal so: Als Gosling & Co. bei SUn Java erfanden, konnten sie ja noch keine 10 Jahre praktischer Erfahrung mit ihrem Baby vorweisen, ebensowenig wieder jeder beteiligte Entwickler. Wer weiß schon was die alle vorher programmiert haben... Sehen wir die Java Lib also als Zeitzeugnis, das nicht verändert werden darf (Komm mir jetzt keiner mit der Berliner Mauer!).
@Al: Ich möchte den Hinweis auf die Diskrepanz im Design von System und Runtime bestimmt nicht als Kritik an Gosling verstanden wissen, das würde ich mir nie anmaßen (obwohl: an seiner Frisur könnte er mal arbeiten); ich wollte nur zeigen, dass die Entscheidung, ob man in solchen Fällen statics verwendet oder nicht, offenbar nicht immer ganz einfach zu treffen ist.
War auch keine Kritik an deiner Kritik. Ich wollte nur etwas beschwichtigen (auch mich selbst) weil man im Nachhinein beim Aufdeckens solcher Diskrepanzen leicht vergisst, dass auch Java nicht an einem Tag erbaut wurde und jeder wohl selbst weiß wie schwer es ist Projekt zu bauen, dessen API in Stein gemeißelt wird und in 10 Jahren noch 'modern' und gut designt ist.
Manchmal macht man sich aber auch einfach zuviel Köppe um sowas. Ich z.B. habe auch so nen Hang zur Kopflastigkeit, weil da immer diese Unsicherheit ist, die man gerne loswerden will, anstatt sich mit ihr zu arrangieren.
