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.
Wenn ich ein Projekt entwickel, wo ich in verschiedenen Klassen immer wieder die gleichen Methoden verwende, zB public (static) int countXY() - erstell ich dann am Besten eine Klasse, zB PermanentNeededMethods und schreib die da rein?
Und wenn ich sie benutzen will? Erstell ich dann in jeder anderen Klasse ein PermanentNeededMethods Objekt? Oder schreib ich dann PermanentNeededMethods.countXY()?
Also vllt klingt die Frage bisschen komisch aber ich will mir ja nen guten Stil angewoehnen
Wenn du von PermanentNeededMethods ein Objekt instanziierst, dann macht es keinen Sinn, dass deine Methoden statisch sind. Eclipse warnt in dem Fall sogar.
Ich würde die statischen Methoden in Aufgabenbereiche trennen und in Klassen packen, so dass am Klassennamen erkennbar ist, zu welchem Bereich die Methoden gehören. Ein PermanentNeededMethods.countXY() sagt gar nichts.
Typisch sind Klassen(namen) wie StringUtil, NumberUtils, DateTimeUtils etc. Wie langhaar es schon sagte: einfach nach Themengebieten trennen. Und wenn diese Klassen zu groß werden (~500+ Zeilen), solltest du sie weiter unterteilen (z.B. DateTimeUtils -> DateUtils + TimeUtils).
Solche Hilfsmethoden sind dann so gut wie immer statisch (musst du wirklich ein Objekt deiner StringUtil-Klasse erzeugen, um alle Zeichen eines Strings zu zählen?).
@langhaar!
es geht mir eigentlich nicht drum ob die statisch ist oder nicht. (daher in klammern)
und dass PermanentNeededMethods.countXY() nicht viel aussagt ist schon klar, hab ich jetzt hier halt mal so genannt.
es geht mir um die grundsätzliche struktur.
pack ich die dinger in ne eigene klasse und erzeuge ich ein objekt davon und sprech sie via objekt an?
was ja irgendwie - soweit ich das verstanden hab - nicht ganz im sinne der klassischen objektorientierung wäre, wo man objekte des realen lebens abbildet und diese kommunizieren laesst. - schon klar, dass man nicht immer nur echte dinge abbildet, aber einfach ein objekt von ner hilfsklassen klasse fand ich eben bisschen komisch. daher die frage.
andre möglichkeit, die klasse statisch zu machen und dann via klassenname.methode() ansprechen. aber wahrscheinlich auch komisch...(?)
@darekkay
ok, also kein schlechter stil ne klasse zu erstellen wo 10 kleine statische hilfsmethoden drinstecken?
und wie sprech ich sie dann an?
grob generell gesagt sollte man sich bei solchen Ueberklassen diese sich nochmals genau anschauen. Die Gefahr ist dass sie zu viel machen, also zu viele Verantwortlichkeiten haben und man sie daher besser modularisieren sollte (Single responsibility principle - Wikipedia, the free encyclopedia)
nein ueberhaupt nicht, wenn diese statischen hilfsmethoden wirklich klein sind und nicht noch weitere Abhaengigkeiten haben, erstellen oder nutzen ist dies wesentlich besser als code duplikationen ueberall in seinem Projekt zu haben.
Ein bsp wann eine statische Methode nicht sehr gut ist, ist:
Java:
// in irgendeiner klasse
public void foo() {
Database.connect();
// do something
}
public final class Database {
private Database() {
// static
}
// bsp
public static void connect() {
DatabaseConnection con = new DatabaseConnection();
con.connectToProductiveDatabase();
}
}
hier macht die statische Methode mehr als sie sollte. Von deinem code aus gibt es nun keine moeglichkeit nicht zur produktiven Db zu connecten - du kannst die Abhaengigkeit nicht injecten (argh so viel denglische begriffe).
Simple gute bsp fuer statische Hilfsmethoden -> java.lang.Math
Typisch sind Klassen(namen) wie StringUtil, NumberUtils, DateTimeUtils etc. Wie langhaar es schon sagte: einfach nach Themengebieten trennen. Und wenn diese Klassen zu groß werden (~500+ Zeilen), solltest du sie weiter unterteilen (z.B. DateTimeUtils -> DateUtils + TimeUtils).
Solche Hilfsmethoden sind dann so gut wie immer statisch (musst du wirklich ein Objekt deiner StringUtil-Klasse erzeugen, um alle Zeichen eines Strings zu zählen?).
Mal so am Rande... Was ist denn an java.lang.Math und (z.B.) java.awt.Toolkit auszusetzen, dass man auf die Idee kommt, sich immer irgendwelche XUtils Klassennamen aus den fingern zu saugen? Naja, nun hast dir die Mühe gemacht, aber für's nächste Mal...
Das wäre im übrigen dann noch eine andere Möglichkeit der Namensgebung für Utility- bzw. Toolkit-Klassen - Bestimmt durch die Lage in der Pakethierarchie.
[EDIT]Zu langsam Spacerat! ...nehmt's mir net übel, man wird älter. XD[/EDIT]
Mal so am Rande... Was ist denn an java.lang.Math und (z.B.) java.awt.Toolkit auszusetzen, dass man auf die Idee kommt, sich immer irgendwelche XUtils Klassennamen aus den fingern zu saugen? Naja, nun hast dir die Mühe gemacht, aber für's nächste Mal...
Das wäre im übrigen dann noch eine andere Möglichkeit der Namensgebung für Utility- bzw. Toolkit-Klassen - Bestimmt durch die Lage in der Pakethierarchie.
Bemängelst du die Hilfsklassen selbst oder die Namensgebung XUtil(s)? Für das erste: es gibt Hilfmethoden, die ich brauche, die es aber so noch nicht implementiert gibt. Da dir das sicherlich auch bewusst ist, meinst du wohl das zweite. Die Frage ist - was spricht dagegen, den Klassennamen mit Util zu beenden? Der Name soll doch genau beschreiben, was eine Klasse macht. StringUtil(ities) tut genau das: es beinhaltet Hilfmethoden zum Umgang mit Strings. Apache nutzt selbst eine StringUtils-Klasse, warum auch nicht?
Und was gibt's an Math und Toolkit auszusetzen? Fangen wir mit den 1500 bzw. 2500 Zeilen Code an
Gleiches wird früher oder später jeder StringUtil-Klasse passieren, weswegen man wie erwähnt Code auslagern sollte.
Ich bemängele gar nichts von beiden. Nur wenn man Threads in denen es um solche Klassen geht, beantwortet, überlegt man sich zum Text erst immer irgendwelche (so 6, 8 bis 2) dubiose Namen wie ImageUtils, AudioUtils, meinetwegen noch... ach, da fällt mir jetzt nix mehr ein. Dabei gibt es doch so viele bereits vorhandene Hilfsklassen, deren Namen und Inhalt auch vollkommen berechtigt sind. Irgendwann ist im übrigen in jeder Hilfsklasse mit "Auslagern von Code" schluss. Man fängt in kleinen logisch zusammenhängenden Einheiten an und in naher Zukunft kommen ohnehin zig neue Methoden hinzu, weil sie halt in diesen logischen Zusammenhang passen. Dann hat auch die am besten geplante Hilfsklasse 2000 Zeilen Code.
Ich bemängele gar nichts von beiden. Nur wenn man Threads in denen es um solche Klassen geht, beantwortet, überlegt man sich zum Text erst immer irgendwelche (so 6, 8 bis 2) dubiose Namen wie ImageUtils, AudioUtils, meinetwegen noch...
