Best Practice Wiederverwendung von Klassen

[phil63]

Hallo zusammen,

ich bin ein blutiger Anfänger im Bereich Java. Dazu habe ich mir ein dickes Buch geschnapt und habe angefangen

Jetzt habe ich meine ersten Schritte unternommen und die Beispiele und Listings durchgearbeitet. Dabei habe ich mir einige kleinere Methoden geschrieben, welche ich (so glaube ich) immer mal wieder gebrauchen kann. Auf diese würde ich also in weiteren Programmen gerne zurückgreifen. Jetzt frage ich mich, wie ich dies am besten bei Eclipse händle?

Ich halte es für ziemlich unsinnig, diese Classe(n) immer wieder in das Projekt hinein zu kopieren. Dies würde ja nur dazu führen, dass sich der Speicherplatz mit redundaten Codezeilen extrem aufbläht und bei einer Änderung alle Programme / Kopien der Classen angepasst werden müssen.

Es gibt doch bestimmt einen weg, wie ich dieses einmal zentral schreibe bzw. ablege, in meine Programme importieren kann und bei einer Änderung dies einmal zentral ändere und sich dies entsprechend automatisch in die Programme (zumindest nach einer neuen compilation) einfügt, oder?

Wie gesagt bin noch ganz neu in Sachen Java und Eclipse.

Wie würde man bei einer solchen zentralen Lösung mit Pfadänderungen z.B. durch Neuinstallation des PC's umgehen?

Für eure Hilfe wäre ich sehr dankbar.

Gruß

 

[Kevin94]

In Eclipse gibt es die Möglichkeit andere Projekte genauso wie externe Libs einzubinden.
Einfach ein Projekt mit diesen Hilfsklassen (in einem Package, nicht im default Package, das gibt beim import immer Ärger) anlegen und dann in anderen Projekten einfach über Project -> Properties -> Java Build Path -> Project -> add das entsprechende Projekt hinzufügen und schon sind die Klassen mit dabei.

 

[phil63]

Hy,

danke für die schnelle Antwort.

Also ich würde als erstes einen Windows-Ordner anlegen, welche ich z.B. MeineHilfsklassen nennen.
Danach lege ich ein Projekt mit eigene Package an.

Dieder Import verlinkt also quasi nur und kopiert den import nicht in das neue Projekt? Damit wären Änderungen sofort in allen anderen Projekten drin?

Danke und Gruß

 

[Kevin94]

Du legst in Eclipse ein Projekt in deinem normalen Workspace an, z.B. "Hilfklassen". In diesem Projekt hast du dann ein (oder mehrer) Packages mit deinen Hilfsklassen. In den anderen Eclipse Projekten importierst du dann wie beschrieben dieses Projekt und dein Hilfklassen sind dort verfügbar. Den SourceCode für diese Hilfsklassen hast du dann nur einmal und Änderungen sind sofort in allen anderen Projekten übernommen. Das gilt natürlich nicht für mit export erzeugt .jar Dateien.

 

[phil63]

Hy,

super vielen Dank.
Habe es gleichmal ausprobiert. Es hat super funktioniert.

Allerdings wird mir eine Warnung angezeigt, welche ich nicht ganz verstehe:

public static void main(String[] args) {
		
		myDatenbankConnection dbMySQL = new myDatenbankConnection();
		
		dbMySQL.test1();
		}

The static method test1() from the type myDatenbankConnection should be accessed in a static way


Was habe ich hier falsch gemacht. Der Aufruf der Methode funktiniert aber.

Sollte sich irgentwann eimal der Pfad vom Hilfsklassenprojekt ändern, muss ich den vermutlich immer neu angeben. Kann man den auch nciht fest vorgeben, sondern relativ zur Position des Projektes?

Danke und Gruß

 

[Michael...]

The static method test1() from the type myDatenbankConnection should be accessed in a static way
Was habe ich hier falsch gemacht. Der Aufruf der Methode funktiniert aber.

test1 ist als statische Methode definiert. Daher ist es nicht notwendig/macht auch keinen Sinn diese an einer Instanz der Klasse aufzurufen. Solche Methoden sollten an der Klasse selbst aufgerufen werden - dann kommt man fälschlicherweise nicht auf die Idee, dass man hier etwas Instanzspezifisches bewirkt.

 

[tuttle64]

Wenn Du eine Methode aus einem static-Kontext aufrufst, muss diese Methode ebenfalls static deklariert sein. Abgesehen davon, sollten Utilities Methoden eh static deklariert werden, da man diese ohne die Instantierung der Klasse verwenden möchte!

 

[phil63]

Hy,

ok, das war ja auch nur ein Test

Also wenn ich es richtig verstanden habe, dann

kleine Hilfsmethoden werden static bezeichnet und entsprechend direkt aufgerufen.
Aber eine echte Datenbankverbindung würdet ihr dich auch als Objekt aufrufen (also eine INstanz erzeugen) oder?

Gruß

 

[Kevin94]

Ja, da eine Datenbankverbindung für sie spezifische Daten hat (wie Host, User und Passwort) und gleichzeitig mehrer Datenbankverbindungen nebeneinander existieren können und sollen, ist das sinnvoll sowas in einer Instanz zu kapseln.

 

[phil63]

gibt es da Regeln oder Hinweise, mit denen man entscheidenen kann, wan man mit static-Methoden arbeitet und wann man mit instanzen arbeiten sollte?

Ich wollte z.B. mit einer Klasse anfangen, mit der ein lesen von TXT-Dateien möglich ist.
Nach dem was du geschrieben hast, würde ich das besser so aufbauen, dass man daraus mehrere Instanzen erstellen kann, oder?

Gruß und Danke

 

[Kevin94]

Wann genau man statische Methoden einsetzten soll ist selbst unter ich sag mal erfahrenen Programmierern umstritten. Gibt auch mehrer Threads dazu hier im Forum, aber ein "verbindliche" Richtline gibt es nicht.
Als Hilfestellung zu Entscheidung würde ich sagen, wo immer man statische, nicht finale Variablen anlegt ohne auch Instanzen mit Instanzvariablen zu haben, läuft was schief. Aber ich bin selber nur Hobby-Programmierer, wenn das die anderen anders sehen, korrigiert mich bitte.

 

[Michael...]

Vor allem Anfänger neigen dazu ziemlich viel static zu machen, einfach weil sie es nicht besser wissen oder es eben "einfacher" ist. Das static ist da aber in 99% der Fälle immer falsch. Meine Meinung: so wenig static wie möglich. In der Regel braucht man (mit Ausnahme der main Methode) gar kein static.

static macht Sinn bei Hilfsklassen/Methoden wie z.B die Klasse java.util.Math, die "Funktionen" bieten, die etwas ohne Instanzrelevanz zurückliefern. Es wird beim Singleton Pattern usw. verwendet - für Anfänger kaum bis gar nicht relevant.

Java selbst nutzt es auch für "global" geltende/zugängliche "Konstanten" oder für komfortable Ausgaben per System.out...

 

[Marco13]

@Michael... : Bei der Frage "static oder nicht" ist es IMHO GANZ wichtig, zwischen Fields und Methods zu unterscheiden. Ich hatte schon gelegentlich die "Daumenregel" genannt: Methoden sollte man IMMER static machen, wenn man sie ohne Umstände static machen kann. Fields sollte man NIE static machen, außer bei Konstanten (und den wenigen, hier mal verschwiegenen Ausnahmen (S*****on)).

Aber trotzdem ist die Frage, http://www.java-forum.org/allgemein...embermethoden-statische-utility-methoden.html nicht ganz einfach zu beantworten.

 

[Landei]

Methoden statisch machen ist auch nicht ganz ohne, weil man sie damit sozusagen aus der Vererbung "herausnimmt". Wenn man dann an zig Stellen

Foo.blubb()

stehen hat, aber in einer abgeleiteten Klasse

Bar

gerne

blubb()

überschreiben würde... Pech gehabt.

Natürlich kann man

Bar

eine neue Version von

blubb()

mitgeben, nur bekommt der "alte" Code davon leider nichts mit. Vererbung regelt sowas "automatisch".

 

[Marco13]

Das ist praktisch das einzige Argument("chen"?) gegen statische Methoden in diesem Sinne, und auch im verlinkten Thread etwas ausführlicher diskutiert. Ich finde, das Argument, dass man eine statische Methode leicht aus einer (polymorphen) Methode heraus aurufen kann, recht überzeugend - speziell mit den defender methods aus Java 8 ( Virtuelle Erweiterungsmethoden (virtual extension methods) in Java 8 ).

Man könnte mal wieder lapidar sagen: YADC, yet another design choice, das muss man halt machen, wie man meint, es sei richtig. Aber wie schon im anderen Thread gesagt: Irgendeine (formale, evaluierbare) Grundlage, auf der man die Entscheidung treffen könnte, wäre nicht schlecht...

 

[phil63]

Hallo,

Ihr habt mir aufjedenfall weitergeholfen.

Vielen Dank

Gruß