Der Sinn von Packages

Hallo!

Aber noch ein netter wenn vielleicht auch akademisch wirkender Hinweis in Bezug auf die Auswahl von Paketnamen bzw die Zuordnung von Klassen.
Es hat sich auf das erste Thema bezogen durchgesetzt das der erste Name eines paketes möglichst einer Länderkennung gleicht (de für Deutschland) und der 2. Teil sozusagen eine Art Firmer oder Inhaberkürzel. Wichtig dabei ist was eine Art stiller Standard darstellt package-namen grundsätzlich klein zu schreiben.
Zum Vergrößern anklicken....
ich denke das hatte vor allem die Bewandniss, dass moeglichst keine/kaum/geringe Namensraum Ueberschneidungen auftreten...

Gruss Tom
 
vielen dank für eure hilfe!

aber ich verstehe noch nicht ganz was es mit dieser zyklischen abhängigkeit auf sich hat...
was soll den so schlimm daran sein wenn man klassen von einander abhängig macht? ist das nicht normal?
 
Was takidoso meint ist, dass du Klassen schlecht wiederverwendbar machst, wenn diese immer nur funktionieren, wenn sie bestimmte andere Klassen brauchen, um zu funktionieren. Je mehr du eine bestimmte Funktionalität in einer Klasse kapseln kannst und diese Klasse unabhängig von anderen Klassen einsetzen kannst, desto höher ist ihre Wiederverwendbarkeit.

Solche Beispiele findet man auch im wirklichen Leben, nur fällt mir jetzt spontan keines ein.

Nungut ein etwas krummes Beispiel. Du hast zwei Festplatten. Eine interne IDE Festplatte und eine externe mit USB Anschluss. Die interne kannst du nur in einem normalen PC verbauen, da diese einen Stromanschluss und einen Anschluss an den Datenbus benötigt. Eine USB Festplatte benötigt nur einen USB Port. Solch einen haben schon viele Endgeräte heute, also ist ihre Wiederverwendbarkeit etwas höher als die der internen. Ich hoffe das geht als Beispiel durch gnihihi. :) ..
 
Prophet05 hat gesagt.:
vielen dank für eure hilfe!

aber ich verstehe noch nicht ganz was es mit dieser zyklischen abhängigkeit auf sich hat...
was soll den so schlimm daran sein wenn man klassen von einander abhängig macht? ist das nicht normal?
Zum Vergrößern anklicken....
Also es kann durch aus passieren und ist erlaubt dass Klassen gegenseitige Abhängig keit haben. Diese solten dann aber bitte im selben Package liegen, damit die Pakete, wenn sie in 2 Pakete täte, nicht gegenseitig abhängig sind.
Denn meist ist es ja so, dass man nicht nur einzelne Klassen wiederverwenden möchte sondern ganze Bibliotheken, also grob gesagt Pakete.
Hat man nun das Phenomen, dass man sich nicht o richtig entscheiden kann ob nun die 2 Klassen in das eine oder das andere Paket gehen sollen, bzw ihre Aufgabe so erscheint, dass die eine in das eine und die andere Klasse in das andere Paket gehen soll, hat man irgendwas unglücklich gestaltet. In solchen Fällen sollte man überlegen, ob entweder wirklich in das selbe Paket gehen oder ob man die 2. Abhängigkeit (Klasse 1 abhänggi von Klasse 2 und Klasse2 abhängig von Klasse1) aufweicht. Aufweichen kann man mit z.B. der Listenerpattern oder anderen Call-back ähnlichen Konstrukten.

Takidoso
 
Ok verstanden.

ICh habe weitgelesen und mir fällt auf das oft gesagt wird das manche Bibliotheken nicht auf allen PCs exsistieren. Das erscheint mir unlogisch. Soweit ich das prinzip verstanden habe muss doch der Compilierte Bytecode nur noch (im prinzip genaus wie bei Assembler) von der Runtime environment interpretiert werden. Wo liegt also das Problem wenn man eine bibliothek mit einkompiliert? Warum sollte das programm dann nicht auf anderen PCs laufen? oder habe ich da was missverstanden?

Eine weitere frage ist weshalb ein freund von mir unter Linux meine Jar-Anwendung entpacken und den Quelltext lesen konnte? Das dürfte doch eigentlich nicht sein... Wie kann ich das verhindern? Ich benutzte Eclipse was muss ich einstellen damit das Programm nicht mehr geöffnet werden kann?

Ich habe mir jetzt einfach einen neune Thread gespart...

mfg Prophet05
 
Also Bibliothekn in Java sind halt jar-Dateien. Vermutlich Dir auch bekannt. Es ist durchaussinnvoll die fremden bibliotheken, die man verwendet so zu belassen wie sie sind und lediglich im classpfad einzubinden. bei Auslieferung eines Programms sollte man natürlich vorsichtshalber auch die nicht selbst produzierten aber benötigten .jar Dateien ausliefern. am besten in einem Verzeichnis zB. mit dem typischen Namen lib. Wenn die Anwendung dann mittels Batch-Datei ausgeliefert wird referenziert sie mit dem Classpfad für den Aufruf auf diese diversen .jar-Dateien.

Entweder hattest Du die Sourcen mit in Deiner Jar-datei gehabt (ungewöhnlich) oder Er hat einen Recompiler (manche nennen sowas auch Decompiler) Der macht aus class-Dateien wieder Sourcecode, jedoch natürlich ohne Kommentare. Gegen solches kann man einen sogenannten Obscurator (ich nenne sowas auch gerne Sorucecode-Schredder) verwenden. der geht her und verändert creativ die Bezeichnungen. Ich weiß zwar nicht ober es welche gibt die das direkt aus .class dateien machen oder in einem Zwichenschritt der Sourcecode verwendet wird. Das din ist halt wenn man dann die .class Dateien mit einem Recompiler anschauen will sieht man das vielleicht eine Klasese x eine methode y(a1,a2,a3) aufruft. Also in anderen Worten es wird nicht nachvollziehbar. Diese mehtode hat aber auch einen nachtiel. Exceptiontraces dürften dannicht besonders aussagekräftig sein. das wäre dann der Preis ;-)

Takidoso
 
Wenn ich aber nun per import die Bibliothek/Klasse einbinde so wird sie doch mit eingebunden oder? Wie kann es dann sein das sie woanders fehlt? Wie kann ich sie ganz sicher mit eincompilieren?

Er konnte meinen Source mit Kommentaren sehen. Soweit ich weis hat er es einfach entpackt (*.jar ist doch im prinzip nur ein umbenanntes zip oder?). Wie gesagt ich nutze Ecliose wenn jemand weiß wie ich das ganze so compiliere das es nicht mehr "einfach" so zu lesen ist wäre ich sehr glücklich. Gegen Decompilieren kann man wohl nichts machen. aber eigentlich dachte ich immer das das nicht möglich ist, weil es ja im prinzip genau wie bei C++ assambler/bytecode nicht in quelltext verwandelt werden kann...

mfg Prophet05
 
Import statements geben nur an das weitere Pakete benötigt werden. Findet der Compiler mittels seines gesetzten Classpfades bereits die richtigen class bzw jars und sind sie aktuell oder gar keine Sourcen vorhanden (genaugenommen ist das dann wieder ein Zusammenspiel mit der IDE) dann ist alles ok. Beim Laufenlassen der Anwendung werden natürlich auch diese jars bzw .class dateien benötigt. einige IDE sind in der Lage zwar auch aus schon vorliegenden jars die einzelenen Klassen (class-dateien) mit in ein Ziel-jar, in dem dann auch die eigenen Klassen liegen, zu packen. Aber ob man das immer machen sollte, ist Geschmacksache. Ich weiß von JBuilder das er diese Möglichkeit in seinem Wizzard zur Jar-Dateibildung (Archivuilder) anbietet. Wie das in Eclipse ist weiß ich nicht.
Demnach hat Dein Freund ein Jar bekommen wo auch der Sourcecode enthalten war. also ich denke mal Du musst versuchen die jar-bildung entsprechend anzupassen, leider bin ich noch kein Eclipse experte, aber vielleich werde ich ja nch einer, da ich z.Z. mich damit auch langsam auseinandersetzte.

Der Byte-code von Java ist mit sammt den Bezeichnungen tatsächlich recompilierbar. Aber wie gesagt, mit einem Obscurator (im JBuilder höherer Editionen nennt man das auch Code versiegeln) ist das möglich dem jenigen der ein Programm recompiliert keine Freude damit zu bereiten :-).

Takidoso
 
Ok danke.

Dann wäre ich dankbar für jeden der mir erklärt wie man Klassen mit in die Jar einfließen lässt und ich es hinkriege das man das ganze nicht einfach entpackt und alles sieht...
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück