Ein paar theoretische Fragen

[Antoras]

Hallo,

ich hätte da mal ein paar Fragen zu denen ich noch keine zufriedenstellende Antwort gefunden habe:

• Sollte man es vermeiden Methoden selbst in abstrakten Klassen auch auf abstract zu setzen? Bisher hab ich überall gelesen, dass nur Attribute mit diesem Sichtbarkeitswert ausgestattet werden sollten. Gibt es da einen bestimmten Grund dafür?
  
• Ist es - bis auf die Schreibarbeit - von Nachteil, zusätzliche Befehle wie setText() zu benutzen? Also statt
  

  JButton b = new JButton("neuer Button");

  so etwas zu schreiben:
  

  JButton b = new JButton();
  b.setText("neuer Button");

  Also ich mein, besitzt das Programm bei letzerem mehr Ausführungszeit /Speicherverbrauch (oder sonst was), weil hier zwei Befehle vorhanden sind, oder kommt das auf's gleiche raus?
  Genau das gleiche gilt ja auch für
  

  import javax.swing.*;

  oder
  

  import javax.swing.JFrame;

  Kostet es zusätzliche Leistung, dass bei ersterem mehr Pakete importiert werden, oder kommt das auch aufs gleiche raus (von der Übersichtlichkeit mal abgesehen)?
  
• Es gibt ja verschiedene Layoutmanager. Aber gibt es einen, den man bevorzugt einsetzen sollte?
  Ich benutze beispielsweise immer GridBagLayouts, da mir z.B das GroupLayout zu viel zum schrieben ist. Form- oder SpringLayouts gehen ja in die gleiche Richtung wie das GroupLayout(wobei mir die Unterschiede noch nicht so richtig klar sind, aber jetzt egal). Ich weiß, die kann man nicht wirklich vergleichen, funktionieren ja anders und haben jeweils Vor-und Nachteile. Aber theoretisch kann man mit den meisten Layouts am Ende das gleiche Ergebnis erzielen, oder?
  Ich weiß, dass ist schwer zu beantworten und hängt wohl auch von den persönlichen Vorlieben ab? Eigentlich will ich nur wissen ob ein GroupLayout bei einem ganzen normalen Swing-frame vollkommen ausreicht? Oder hab ich hier eine falsche Vorstellung von den Möglichkeiten und Anwendungsgebieten der unterschiedlichen Layouts?

Das wars erstmal. Mir fällt aber bestimmt noch mehr ein.

 

[mvitz]

zu 3)
Nein es kostet dich nicht mehr, wenn du

import javax.swing.*;

schreibst, da es gar kein import in dem Sinne ist. Du sagst damit nur, dass wenn du eine Klasse "JFrame" benutzt er diese aus dem Paket javax.swing nehmen soll und nicht aus Paket y.x. Ohne den import müsstest du dann schreiben:

javax.swing.JFrame frame = new javax.swing.JFrame("Test");

import dient also nur der Übersichtlichkeit des Quelltextes.

 

[Beni]

Zu 1: abstract hat nichts mit Sichtbarkeit zu tun, insofern verstehe ich die Frage nicht... es kann durchaus sinnvoll sein, abstrakte Methoden zu definieren.

Zu 2: Wieviele Abermilliarden JButtons generiert dein Programm, dass du dir um sowas Sorgen machst?
Je nach Implementierung ruft der Konstruktor entweder selbst "setText" auf (also kein Gewinn) oder setzt den Text direkt (Gewinn im Nanosekunden-Bereich).

 

[Templon]

Sollte man es vermeiden Methoden selbst in abstrakten Klassen auch auf abstract zu setzen?

Für was machst du eine abstrakte Klasse, wenn du keine abstrakten Methoden möchtest? Oder habe ich dich da falsch verstanden? =)

Bisher hab ich überall gelesen, dass nur Attribute mit diesem Sichtbarkeitswert ausgestattet werden sollten. Gibt es da einen bestimmten Grund dafür?

abstrakt ist kein Sichtabrkeitswert (Ich denke du meinst access modifier (k.A. wie der Deutsche Begriff heisst =) )) Hier etwas über access modifier http://java.sun.com/docs/books/tutorial/java/javaOO/accesscontrol.html und hier über abstrakte Klassen/Methoden http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html

 

[hdi]

Also 2) und 3) wurden ja schon beantwortet und sind auch nicht so wichtig.

Aber das mit den abstrakten Methoden sollte dir schon klar sein, ich glaube hier tappst du grad
völlig im Dunklen. "abstract" definiert keine Sichtbarkeit, sondern geht eher in Richtung Interface.

Ich hab dazu mal was geschrieben:

Runterscrollen bis "Schlüsselwort abstract"

 

[Antoras]

Sollte man es vermeiden Methoden selbst in abstrakten Klassen auch auf abstract zu setzen? Bisher hab ich überall gelesen, dass nur Attribute mit diesem Sichtbarkeitswert ausgestattet werden sollten. Gibt es da einen bestimmten Grund dafür?

Ach verdammt, hier hatte ich mich verschrieben. Sry. Ich meinte nicht abstract, sondern protected. Also ob/warum man Methoden selbst in abstrakten Klassen nicht auf protected setzen soll.

Zu meiner zweiten Frage:
Stimmt, eigentlich ist das eine sinnlose Frage - mal in der heutigen Zeit. Bei der Rechenleistung heutiger PC fällt ein Befehl mehr oder weniger nicht ins Gewicht. Aber hätte ja sein können, dass das bei Programmen mit 100.000+ Zeilen Code bedeutende Unterschiede gemacht hätt, deswegen hat es mich mal interessiert. Aber Programme dieser Größenordnung werd ich wohl noch nicht so schnell schreiben...

Also 2) und 3) wurden ja schon beantwortet und sind auch nicht so wichtig.

Ähem nein. Nummer 3 (Layoutfrage) wurde noch nicht beantwortet.

 

[Beni]

Ok, 3: Ausprobieren und Beispiele angucken. Es gibt keinen "besten" LayoutManager.

Nochmal 2: ich kann dir auch mit 3 Zeilen ein Endlos-Programm schreiben. Die Anzahl Zeilen bestimmt nicht die Geschwindigkeit eines Programmes :bae:

Zum abstract und protected: ich schreibe öfters protected Methoden in abstrakten Klassen. Eine abstrakte Klasse ist ja sozusagen nur "halb fertig", da macht es IMHO schon Sinn grosse Teile der Klasse für die Subklassen verfügbar zu machen.
Beispiel: einer abstrakten Klasse können ABCListeners angehängt werden und die Klasse verschiesst ABCEvents. Die Mehode zum verschiessen der Events ist protected weil Subklassen allenfalls auch ABCEvents verschicken müssen.
Ich frage mich eher wieso man Attribute protected machen sollte, hier hätte ich auf private getippt (aber vielleicht lese ich die falschen Bücher?).

 

[Antoras]

Ich frage mich eher wieso man Attribute protected machen sollte, hier hätte ich auf private getippt (aber vielleicht lese ich die falschen Bücher?).

Naja, ich hab es so gelernt, dass man in den abstrakten Klassen alle Attribute/Methoden "sammelt" die in jeder Unterklasse ebenfalls vorkommen. Nun kann man auf die Methoden und Attribute dieser Klasse zugreifen und muss sie nicht in jeder Klasse neu deklarieren. Wenn man jetzt die Unterklassen ansprechen möchte, dann braucht man ja nur noch die abstrakte Klasse ansprechen, bekommt aber alles geliefert was man braucht. Wenn nun Methoden/Attribute auf private sind, dann kann man sie ja nicht vererben. Und bei public kann ja wieder jeder auf die Objekte zugreifen.

Das Zugreifen von anderen Packages muss ja aber nicht unbedingt sein. Ich hab nur überall gelesen, dass man die Methoden trotzdem öffentlich lassen soll. Aber das macht ja keinen Sinn, wenn ich sie nur in einen Package haben möchte.

 

[hdi]

Ich hab nur überall gelesen, dass man die Methoden trotzdem öffentlich lassen soll. Aber das macht ja keinen Sinn, wenn ich sie nur in einen Package haben möchte.

..die Frage ist, ob du das möchtest. Nur, weil dein Programm auf blöd nur ein einziges Package hat, heisst das nicht dass du alle public Dinge protected machen sollst. Würde zwar keinen Unterschied machen, aber protected impliziert nun mal, dass du unbedingt nur in diesem Package die Sichtbarkeit willst. Und dafür braucht man immer einen guten Grund.

Mit public und private ist das etwas anders, denn private liegt auf einer ganz anderen Ebene, sag ich mal so und hoffe dass man es versteht Worauf ich hinauswill: Nutze immer nur private oder public, und lass protected links liegen. Ausser, du hast den o.g. guten Grund, warum protected, und nicht public (oder nicht private!). So schnell findet man so einen Grund aber in einer kleineren Anwendung nicht.

 

[Antoras]

Aha ok. Also sollte ich (wenn ich keinen trivialen Grund habe) komplett auf protected verzichten - sowohl bei Methoden als auch bei Attributen.

Gut, dann hätten sich die Fragen mal erledigt.

Danke für die Antworten.

 

[CiD]

zu 3)
Nein es kostet dich nicht mehr, wenn du

import javax.swing.*;

schreibst, da es gar kein import in dem Sinne ist. Du sagst damit nur, dass wenn du eine Klasse "JFrame" benutzt er diese aus dem Paket javax.swing nehmen soll und nicht aus Paket y.x. Ohne den import müsstest du dann schreiben:

javax.swing.JFrame frame = new javax.swing.JFrame("Test");

import dient also nur der Übersichtlichkeit des Quelltextes.

Ich habe es so gelernt das durch die "import"-Anweisung genau diese Klassen in den Speicher geladen werden. Also im Bsp. bei "import javax.swing.JFrame;" eben nur diese eine Klasse. Bei "import javax.swing.*;" alle Klassen dieses Paketes.
Wenn man danach geht verbraucht ein "import ....*" (Sternimport) mehr Speicher als ein konkreter import ?

 

[André Uhres]

1234567890

 

[andre111]

Ich find das TableLayout immer ganz praktisch.

 

[Antoras]

JFrame hat ja BorderLayout als "bevorzugten" Layoutmanager, wenn man nix anderes setzt.

Das Problem an dem Layout ist, dass es mir nur die Grundstruktur zur Verfügung stellt. Denn die einzelnen Elemente muss ich ja trotzdem noch richtig auf dem jeweiligen BorderLayout-Bereich anordnen. D.h. dieses Layout würde mir nur die Anordnung der Panels, auf die ich zeichne, liefern.

Ich hatte eigentlich schon vor erstmal ohne GUI-Builder meine Oberflächen zu erstellen. Das GridBagLayout finde ich da durchaus übersichtlich wenn man sich damit auskennt. Mit dem GroupLayout arbeite ich ohne GUI-Builder sowieso nicht.

Bei manuellem Einsatz (also ohne GUI Builder Tool) würden wir wohl benutzerfreundliche Layoutmanager vorziehen.

Mir sind die auch am liebsten. Das Problem ist nur, dass die oft zu einfach sind.
Beispiel:
Ich würde gerne mehrer Reihen Buttons/Textfelder erstellen, diese aber klar von einander abgrenzen. Ein BorderLayout kommt also nicht in Frage, wenn diese Reihen alle untereinander platziert werden sollen und wenn sich ganz unten noch ein Panel, auf das gezeichnet werden kann, befindet.
Deswegen bin ich zum GridbagLayout gewechselt. Hab einfach zwei Panels platziert, auf das obere die Buttons/Textfelder angelegt und auf das untere eben gezeichnet.

Und da hat sich für mich eben die Frage gestellt ob diese Methode die beste ist.

Ich find das TableLayout immer ganz praktisch.

Das hört sich interessant an. Nur leider hat dieses Laoyut das Problem, dass es nicht auf jedem JDK läuft. Wenn ich also an unterschiedlichen Rechnern arbeite müsste ich bei diesem jedes Mal das Layout ergänzen.

Apropos: Wie macht man das überhaupt? Ich hab auf Anhieb keine Anleitung gefunden, in der srin steht was ich mit dem jar-Archiv machen soll.

 

[andre111]

Du kannst die .jar fürs TableLayout ja bei deiner Anwendung die es benötigt mit liefern bzw. die kompletten .class Files von TableLayout mit in deine Anwendung packen (irgendwo in der FAQ is da n Beitrag dazu).

 

[André Uhres]

1234567890

 

[Antoras]

Du kannst die .jar fürs TableLayout ja bei deiner Anwendung die es benötigt mit liefern bzw. die kompletten .class Files von TableLayout mit in deine Anwendung packen (irgendwo in der FAQ is da n Beitrag dazu).

Darüber hab ich auch schon nachgedacht wobei das natürlich trotzdem umständlich ist. Aber an sich ist es ja wurscht - wenn mir das Layout gefällt, dann beschränkt sich der Aufwand zum importieren auf einmal Strg-C und Strg-V.

Auf den Unterpanels (Baumstruktur) kann man ja wieder Border-,Box-,Flow-,Grid-Layout beliebig kombinieren. Ist aber vielleicht nicht jedermanns Sache, denn dazu braucht man wohl schon ein besseres Programmiergefühl und Übung mit den Standardlayouts.

Dieses Gefühl hab ich mittlerweile (glaube ich) schon Zusammengesetzte Layouts sind nur umständlich. Und bei komplexen Oberflächen nicht unbedingt sinnvoll. Na mal schauen. Werde wahrscheinlich bei GridBag bzw. diesem TableLayout bleiben. Und bei kleinen Applets bin ich Flow, Grid und Border dankbar...

 

[andre111]

Also mit TableLayout kann man fast die gleiche Funktionalität erreichen wie GridBadLayout, aber bei TableLayout weis man wenigstens genau was es macht

 

[Spin]

Das Thema nennt sich ja theoretische Frage zu Java.

Kann mir mal bitte noch einmal in 2 Sätzen erklären , was this bedeutet?

Am besten im Bsp. von einem Konstruktor:

public class hallo()
{


private String ab;

hallo()
{
} // Standartkonstruktor

hallo( String a)
{
this.ab = a
}



Nun habe ich ja ein Objekt: Hallo p = new Hallo();

und mit p kann ich dem String ein Wert zu weisen.
this ruft sich ja auch impliziet auf. In meinen bsp, habe ich es expliziet gemacht. Beschriebt this den Weg zum Speicher?

Die Referenz p kann ja mehrere Werte annehmen. und this beschreibt dann den weg zu jeder einzelnen referenz.
--> aufen heap'!


Ist das so richtig?

 

[Ariol]

this ist eine Referenz auf sich selbst.

So sieht du es evtl besser:

public class hallo()
{


private String a;

hallo()
{
} // Standartkonstruktor

hallo( String a)
{
this.a = a;
} 
}

"this.a" ist hier das private Attribut a der Klasse, während
"a" der Parameter der Methode ist.

Ein anderes Beispiel wäre, wenn es wenn "a" ein öffentliches Attribut wäre:

public String a;

Innerhalb deiner Klasse kannst du dann mit "this.a" auf dieses Attribut zugreifen.
Außerhalb, wenn du ein Objekt (z.B. "Hallo p = new Hallo();") erstellt hast mit "p.a".