beans

[maxxi]

hello,

kann mir wer erklären, wozu man Beans braucht und wann man sie verwendet?

Habe mir gerade in einem Buch das Kapitel "Beans" durchgelesen. Aber ich sehe keinen Sinn darin. Java ist eine objektorientierte Programmiersprache. Der Vorteil von OOP ist, dass Scripts leicht wiederverwendbar sind. Wozu brauche ich also noch Beans?

Hm .. ich versteh das nicht :noe:

 

[bygones]

Der Vorteil von OOP ist, dass Scripts leicht wiederverwendbar sind.

uff... wenn das die Aussage deines Buches ist - werf es weg....

 

[maxxi]

Du bist der gegenteiligen Meinung? Alles, was in OOP programmiert ist, ist nicht wiederverwendbar?

 

[maki]

Was deathbyaclown sagte, war:

uff... wenn das die Aussage deines Buches ist - werf es weg....

Diese Aussage ist ja auch Quatsch:

Der Vorteil von OOP ist, dass Scripts leicht wiederverwendbar sind.

Also, wenn das wirklich genau so in deinem Buch steht, wirf es weg

 

[maxxi]

Na OK. Ihr habt mich überzeugt. Ich nehm jetzt alle meine Bücher aus meiner kleinen Bibliothek und mach damit ein kleines Grillfest :smoke:

EDIT:
Oh: ich habe die Ordner noch vergessen. Die müssen auch noch auf den Scheiterhaufen. Und wenn ich schon dabei bin, schmeiß ich die Lehrer auch gleich drauf

 

[bygones]

Na OK. Ihr habt mich überzeugt. Ich nehm jetzt alle meine Bücher aus meiner kleinen Bibliothek und mach damit ein kleines Grillfest :smoke:

yammi lecker wurst...

ich meinte wenn die einzige Aussage die man aus dem Buch bekommt ist, dass OOP deswegen verwendet wird weil man Wiederverwendbarkeit bekommt, dann ist das Buch schlecht...

OOP ist ein bisschen mehr (und vor allem keine Skripte).

zu deiner ersten Frage: JavaBeans ? Wikipedia

 

[maxxi]

Ja, das kenn ich ja schon alles. Alles schon im Buch gelesen. Aber ich verstehe den Nutzen nicht.

EDIT: wer hat denn behauptet, dass Wiederverwendbarkeit der einzige Nutzen von OOP wäre? Aber es wird hoffentlich keiner behaupten, dass OOP NICHT wiederverwendbar wäre.

 

[bygones]

Der Vorteil von OOP ist, dass Scripts leicht wiederverwendbar sind.

diese Aussage ist nun einfach halt falsch....

und der Nutzen steht doch bei wikipedia u.a.

JavaBeans entwickelten sich aus der Notwendigkeit heraus, GUI-Klassen (AWT, Swing) einfach instanziieren (Reflexion) und übertragen (RMI) zu können. JavaBeans werden auch als Container zur Datenübertragung verwendet

jedes simple ValueObject ist eine Bean (bzw kann als eine ausgelegt werden)

public class Person implements Serializable {
  private String name;
  private String street;

  // getter-setter
  }

ergo zum simplen Speichern von Daten...

 

[maxxi]

Ich habe schon gelesen, dass man Beans serialisieren kann. Aber warum sollte ich das machen wollen?

Beispiel:

Ich habe eine Klasse "Haus" mit einer Eigenschaft "Farbe". Jetzt könnte ich aus dieser Klasse eine Bean machen, die Farbe ändern und dann alles serialisieren.

Ich könnte aber auch die Klasse einfach nur Klasse sein lassen, d. h. NICHT in eine Bean umwandeln. Dann einfach nur im Konstruktor die Möglichkeit anbieten, die Farbe zu übergeben. Et voila. Funktioniert genauso. Bei dieser Variante weiß ich auch, was Sache ist. Da ist die Farbe dann ganz klar definiert. Beim deserialisierten Bean ist das nicht der Fall. Dort ist es eher Glückssache, welche Farbe ich dann habe. Vielleicht wohn ich dann plötzlich in einem lila Haus.

 

[SlaterB]

wozu braucht man in Java Dateizugriffe, Netzwerk, graphische Oberflächen, .., .., ..
ich kann doch einfach meine Klasse Haus schreiben und hab sie dann fertig, was brauch ich mehr?

ok, du hast ja gesagt dass du gerade fragst, wozu die Beans da sind, aber die Haus-Klasse ist ein schlechtes Argument,
andererseits auch ganz gut: solange du nur bestimmte Programme schreibst brauchst du dich gar nicht um all den anderen höheren Kram kümmern,
das kommt nach und nach, wenn du es benötigst

 

[maxxi]

Mit "höheren" Kram meinst du die Thematik "Beans"? Oder meinst du damit irgenwas ISO-OSI-Schicht-Applikations-krimskrams-mäßiges?

Was wäre denn ein typischer Fall, wo die Welt und das ganze Universum untergeht, wenn man nicht mit Beans arbeitet?

Oder anders gefragt: gibt es irgendwelche Sachen, wo ich Beans unbedingt brauche, weil ich es ansonst nicht programmieren könnte?

 

[maki]

Was wäre denn ein typischer Fall, wo die Welt und das ganze Universum untergeht, wenn man nicht mit Beans arbeitet?

Oder anders gefragt: gibt es irgendwelche Sachen, wo ich Beans unbedingt brauche, weil ich es ansonst nicht programmieren könnte?

Viele Frameworks basieren auf dem Beansstandard für Getter- und Setternamen.

 

[SlaterB]

wie erwähnt z.B. GUI-Komponenten,
eine JTable steht nicht für sich sondern ist in einem JFrame vernetzt, in einem Layout, einem Datenmodel, verfügt über Listener, 3000 Zeilen Verarbeitungslogik-Code und hunderte temporäre Klassenattribute,
belegt im Arbeitsspeicher mal locker zig KB,
das möchte man nicht alle serialisieren,
sondern ein einfaches Bean mit Name, Id und vielleicht noch 3 Werten, je nachdem worum es einem gerade geht

 

[maxxi]

Viele Frameworks basieren auf dem Beansstandard für Getter- und Setternamen.

Das ist ja gut und schön. Aber mir stürzt der PC nicht ab, wenn ich getter- und setter-Methoden ohne Beans verwende. Dazu brauche ich keine Beans.

eine JTable steht nicht für sich sondern ist in einem JFrame vernetzt, in einem Layout, einem Datenmodel, verfügt über Listener, 3000 Zeilen Verarbeitungslogik-Code und hunderte temporäre Klassenattribute,
belegt im Arbeitsspeicher mal locker zig KB,

Kann ich mir mit Beans nicht ersparen. Mit Beans wird der Code auch nicht weniger.
Was hindert mich daran, statt dem Bean einfach eine total simple Wrapper-Klasse zu programmieren ... eben mit diesen paar Parametern, die ich dem Konstruktor übergeben?

das möchte man nicht alle serialisieren,

Da widersprichst du dich jetzt doch selbst, oder? Die Serialisierung ist doch schließlich eines dieser markanten Merkmale von Beans, oder?

 

[maki]

Das ist ja gut und schön. Aber mir stürzt der PC nicht ab, wenn ich getter- und setter-Methoden ohne Beans verwende. Dazu brauche ich keine Beans.

Irgendwie habe ich das Gefühl dass du entweder ein Troll bist, oder ganz schön auf dem Schlauch stehst.

 

[maxxi]

Sag noch einmal Troll zu mir, dann frage ich dich, wie man in PHP ein Formular für einen Member-Bereich programmiert.

Mein Problem ist, ich kann kein MUSS finden, Beans einzusetzen. :noe:

 

[maki]

Sag noch einmal Troll zu mir, dann frage ich dich, wie man in PHP ein Formular für einen Member-Bereich programmiert.

OK, dann bist du wohl ein AufDemSchlauchSteher

Mal ernsthaft, du fragst wozu man JavaBeans braucht, du bekommst Antworten, bist dann aber Beratungsresistent...

Kann ich mir mit Beans nicht ersparen. Mit Beans wird der Code auch nicht weniger.
Was hindert mich daran, statt dem Bean einfach eine total simple Wrapper-Klasse zu programmieren ... eben mit diesen paar Parametern, die ich dem Konstruktor übergeben?

Gar nichts hindert dich daran, aber in so einem Fall nimmt man dann doch ein sog. TransferObject (Muster) und den passenden TransferObjectAssembler.

Wichtig ist, dass wenn du JavaBeans brauchst, sei es für ein Framework oder fürs Serialisieren oder beides, dann solltest du welche haben, klar, oder?

Mein Problem ist, ich kann kein MUSS finden, Beans einzusetzen

Das liegt wohl daran, dass du eben keine Frameworks einsetzt und auch nicht serialisierst, oder?

 

[SlaterB]

bei dem Ton vegeht mir auch die Lust zu helfen, aber hier noch zwei intelligente Rückfragen beantwortet:

Kann ich mir mit Beans nicht ersparen. Mit Beans wird der Code auch nicht weniger.
Was hindert mich daran, statt dem Bean einfach eine total simple Wrapper-Klasse zu programmieren ... eben mit diesen paar Parametern, die ich dem Konstruktor übergeben?

niemand hindert dich, und falls du noch einen Fachbegriff für die 'total simple Wrapper-Klasse' suchst: Bean
(mehr oder weniger)

Da widersprichst du dich jetzt doch selbst, oder? Die Serialisierung ist doch schließlich eines dieser markanten Merkmale von Beans, oder?

ich sagte dass man das JFrame mit 50kb nicht serialisieren will bzw. auch gar nicht vollständig kann,
sondern stattdessen eine Bean von 300 Byte serialisiert

 

[maxxi]

AufDemSchlauchSteher

Jo, eh. Darum hab ich ja das Thema aufgemacht. Ich will ja diese Beans verstehen.

ich sagte dass man das JFrame mit 50kb nicht serialisieren will, sondern stattdessen eine Bean von 300 Byte serialisiert

Es werden dann nicht die gesamten Klassen, also das komplette Paket, das zur Bean gehört, serialisiert???
Muss ich gleich noch einmal durchlesen im Buch....

JavaBeans entwickelten sich aus der Notwendigkeit heraus, GUI-Klassen (AWT, Swing) einfach instanziieren (Reflexion) und übertragen (RMI) zu können. JavaBeans werden auch als Container zur Datenübertragung verwendet

Also entweder verstehe ich das falsch, oder dieses Prinzip ist kokolores. Habe ich das richtig verstanden, dass man an Position A z. B. eine Klasse programmiert, die irgendwas verarbeitet und dann am Bildschirm anzeigt? D. h. anzeigen würde, es aber nicht tut, weil es dann serialisiert z. B. an Position B übertragen wird? Und erst dort erfolgt dann die eigentliche Ausgabe auf dem Bildschirm (basierend auf der Programmierung, die an Position A schon durchgeführt wurde)? Wenn ich das richtig verstanden habe, würde das doch dem Template-Prinzip widersprechen. Normalerweise werden zuerst alle Daten verarbeitet, das Ergebnis dann übertragen und dann erst am Schluss am Bildschirm angezeigt (wobei sich dann ausschließlich Position B um die Ausgabe kümmert). Ist doch so, oder?

Hm ... das ist seltsam. Muss ich auch nochmal im Buch durchlesen.

Kaffeepause in der Sonne mit Buch und Zigarette .... :smoke:

 

[Ebenius]

Das älteste Beispiel für den Einsatz von Beans ist der GUI-Editor. Wenn man eine Benutzeroberfläche zusammenbauen möchte, ohne alles Zeile für Zeile ausprogrammieren zu wollen, kann man einen GUI-Editor verwenden. Natürlich muss dieser Editor Eigenschaften der verschiedenen Komponenten anzeigen und verändern können; zum Beispiel den Text eines Labels, die Hintergrundfarbe eines Panels, und so weiter. Nun ist es eine schlechte Idee einen GUI-Editor so zu bauen, dass er alle Klassen die man verwenden möchte inhaltlich kennen muss. Man möchte den selben Editor zum Beispiel auch für eine Komponente JXTable verwenden, die der Entwickler des GUI-Editors gar nicht kannte. Deswegen braucht der Editor eine Möglichkeit alle Eigenschaften einer Komponente Abfragen zu können, um diese modifizieren zu können. Er guckt sich also Beispielsweise die JButton-Klasse an und stellt fest, da gibt's eine Hintergrundfarbe vom Typ [c]java.awt.Color[/c], da gibt's eine Schriftart vom Typ [c]java.awt.Font[/c] und so weiter. Dies alles kann er nur tun, weil jemand festgelegt hat, wie die entsprechenden Methoden zum Setzen und Erhalten von Eigenschaften eines Objektes heißen und wie man sie aufruft. Dieser jemand hat das in die Java-Beans-Spezifikation geschrieben.

Das ganze Konzept greift noch ein Stück weiter, aber das ist die Grundlage. Jetzt verstanden?

Ebenius

 

[maxxi]

Das älteste Beispiel für den Einsatz von Beans ist der GUI-Editor.

Davon habe ich in meinem Buch auch gelesen (bin jetzt übrigens nochmals "Komponenten", "Serialisierung", nochmals "Beans" und "RMI" durchgegangen). Und genau wegen diesem GUI-Editor habe ich das Thema geöffnet. Solche GUI-Editoren will ich nämlich vermeiden. Wenn es aber irgendwelche Fälle gibt, wo man Beans unbedingt einsetzen muss, wird mir wahrscheinlich auch nichts anderes übrigbleiben, als mich mit solchen GUI-Editoren zu beschäftigen.

Warum mag ich solche Editoren nicht? Weil ich immer die volle Kontrolle über meinen Quellcode haben möchte. Ich möchte nicht, dass im Hintergrund irgendein Code erzeugt oder (noch schlimmer) verändert wird. Brrr ... ist mir ein Graus.

Natürlich muss dieser Editor Eigenschaften der verschiedenen Komponenten anzeigen und verändern können;

Das habe ich schon verstanden, dass deshalb "Komponenten" (im Grunde genommen sind das ja auch nur normale Klassen) nicht mehr reichen und man eine gewisse Schnittstelle erfinden musste und auf diese Weise zu den "Beans" gekommen ist.

Da du zum Glück diesen GUI-Editor kennst, kann ich jetzt auch noch eine andere Frage stellen:

Bin ich automatisch auf so einen Editor angewiesen, wenn ich mit Beans arbeite?
Wenn nein, wäre der Aufwand sehr groß, das, was der Editor macht, händisch zu programmieren?
Wenn ja, welche Editoren verwendet man denn heutzutage? Mein Buch ist schon aus dem Jahr 2003. Heutzutage wird dieser GUI-Editor gar nicht mehr in Verwendung sein, oder?

Ach übrigens: danke für dein letztes Posting. Ich hoffe, du hilfst mir noch weiter

 

[Ebenius]

Irgendwie bist Du immer noch auf dem Holzweg: Niemand muss irgendwelche Editoren verwenden. Ich habe derartige Editoren oben nur als Beispiel angebracht, wo das Beans-Konzept eigentlich herkommt. Es gibt noch einige andere Beispiele, Serialisierung wurde oben angesprochen.

Dennoch: Alle wiederverwendbaren GUI-Komponenten halten sich an das Beans-Konzept und das ist auch gut so. Du musst dabei eigentlich auch nicht viel beachten. Jede Eigenschaft hat eine [c]get[/c]-Methode (ausgenommen [c]boolean[/c]-Eigenschaften, bei denen gibt's oft statt derer eine [c]is[/c]-Methode; ebenfalls in der Beans-Spec enthalten) und -- sofern die Eigenschaft veränderlich ist -- eine [c]set[/c]-Methode. An viele Beans kann man sich als Zuhörer anhängen ([c]PropertyChangeListener[/c]). In dem Fall werden alle [c]PropertyChangeListener[/c] über den alten und den neuen Wert einer Eigenschaft informiert, wenn diese sich verändert hat. Das war's ganz grob zusammengefasst schon.

Ich benutze niemals irgendwelche graphischen GUI-Editoren, trotzdem ist das Beans-Konzept auch für mich wichtig.

Ebenius

 

[JohannisderKaeufer]

Irgendwie bist Du immer noch auf dem Holzweg: Niemand muss irgendwelche Editoren verwenden. Ich habe derartige Editoren oben nur als Beispiel angebracht, wo das Beans-Konzept eigentlich herkommt. Es gibt noch einige andere Beispiele, Serialisierung wurde oben angesprochen.

Dennoch: Alle wiederverwendbaren GUI-Komponenten halten sich an das Beans-Konzept und das ist auch gut so. Du musst dabei eigentlich auch nicht viel beachten. Jede Eigenschaft hat eine [c]get[/c]-Methode (ausgenommen [c]boolean[/c]-Eigenschaften, bei denen gibt's oft statt derer eine [c]is[/c]-Methode; ebenfalls in der Beans-Spec enthalten) und -- sofern die Eigenschaft veränderlich ist -- eine [c]set[/c]-Methode. An viele Beans kann man sich als Zuhörer anhängen ([c]PropertyChangeListener[/c]). In dem Fall werden alle [c]PropertyChangeListener[/c] über den alten und den neuen Wert einer Eigenschaft informiert, wenn diese sich verändert hat. Das war's ganz grob zusammengefasst schon.

Ich benutze niemals irgendwelche graphischen GUI-Editoren, trotzdem ist das Beans-Konzept auch für mich wichtig.

Ebenius

Standardkonstruktor nicht vergessen!

 

[maxxi]

Niemand muss irgendwelche Editoren verwenden.

Toll! Beans kann man also ohne irgendwelche GUI-Editoren verwenden. Daraus folge ich, dass ich auch keine GUI-Editoren benötige, wenn ich im Internet irgendwo Quellcode sehe, wo Beans verwendet werden. Ich hoffe, das stimmt so. Rein theoretisch könnte man dieses Thema aus meiner Sicht schon als gelöst betrachten. Aber aus purer Neugier frage ich noch zu:

Ich benutze niemals irgendwelche graphischen GUI-Editoren, trotzdem ist das Beans-Konzept auch für mich wichtig.

Wann verwendest DU diese Beans?

 

[bygones]

Toll! Beans kann man also ohne irgendwelche GUI-Editoren verwenden. Danke! :toll:

ich empfehle dir nochmal den Wiki link auf der ersten Seite... da steht recht gut drin dass Beans an sich NIX, aber gar nix mit einem GUI Editor zu tun haben... es ist ein Konzept frei von jeglichen Bindung an eine konkrete Nutzung.

Es werden dann nicht die gesamten Klassen, also das komplette Paket, das zur Bean gehört, serialisiert???

man serialisiert IMMER nur die Bean (also die eine Klasse) - mit den Abhaengigkeiten.... aber nix von kompletten Paketen oder fremden klassen..

Bean = Klasse

 

[Ebenius]

Standardkonstruktor nicht vergessen!

Richtig, der fehlte noch in der Liste.

Wann verwendest DU diese Beans?

Alle Swing-Komponenten sind Beans: JButton, JTable, JList, JLabel, ... verwende ich täglich.

PropertyChangeListener verwende ich recht häufig, wenn ein Teil der Software reagieren muss, wenn sich ein anderer Teil verändert.

Ich habe auch einige Dialoge in meiner Software, in denen der Benutzer Eigenschaften verschiedener Anzeigeelemente einstellen kann; diese Dialoge benutzen java.beans.Introspector und java.beans.PropertyDescriptor. Beans verwendet man irgendwie täglich.

Weiter oben steht's auch schon: Kümmere Dich erstmal nicht weiter darum. Verständnis für solche Konzepte entwickelt man erst mit der Zeit, wenn man die Sprache ein bisschen benutzt hat. Poesie in einer Fremdsprache kann man auch erst greifen, wenn man die Sprache einigermaßen beherrscht.

Ebenius

 

[SlaterB]

Alle Swing-Komponenten sind Beans: JButton, JTable, JList, JLabel, ... verwende ich täglich.

naja, aber serialisieren würdest du das doch nicht, oder?
siehe meine Postings,

wenn du nun JTable als normales Bean deklarierst, dann ist ja kein Wunder, dass die Verwirrung groß ist

 

[byte]

man serialisiert IMMER nur die Bean (also die eine Klasse) - mit den Abhaengigkeiten.... aber nix von kompletten Paketen oder fremden klassen..

Bean = Klasse

Dazu sollte noch gesagt werden, dass beim Serialisieren lediglich die Nutzdaten, also die Werte der Member serialisiert werden, nicht etwa der der Quellcode der Klasse.

In der Serialisierung steht der Fully Qualified Class Name + die Werte der Member. Es spielt also für die Serialisierung keine Rolle, ob die Klasse 1 Methode hat oder 1000.

 

[Ebenius]

naja, aber serialisieren würdest du das doch nicht, oder?
siehe meine Postings,

In der Regel nicht. Aber Beans haben erstmal nix mit Serialisierung zu tun und darauf zielte die Frage des Themeneröffners überhaupt nicht ab. Oder hab ich da was falsch gelesen?

wenn du nun JTable als normales Bean deklarierst, dann ist ja kein Wunder, dass die Verwirrung groß ist

Erstens bin ich nicht verwirrt und zweitens ist eine JTable ein recht normales Bean: Lesson: JavaBeans Concepts (The Java™ Tutorials > JavaBeans(TM))

Sprechen wir irgendwie von unterschiedlichen Themen?

Ebenius

 

[SlaterB]

dass du nicht verwirrt bist ist klar, sondern andere,
aber da selbst auf der Wiki-Seite der JButton als JavaBean genannt wird, sollte ich besser meine Postings als falsch streichen und andere weiter machen lassen

 

[bygones]

das entscheidende ist... JavaBeans sind Serializable

ergo kann man - muss aber nicht...

 

[maxxi]

Alle Swing-Komponenten sind Beans: JButton, JTable, JList, JLabel, ... verwende ich täglich.

Interessant. Ich kenne Swing. War mir gar nicht bewusst, dass das Beans sind.

In der Regel nicht. Aber Beans haben erstmal nix mit Serialisierung zu tun und darauf zielte die Frage des Themeneröffners überhaupt nicht ab. Oder hab ich da was falsch gelesen?

Wollte im Endeffekt nur wissen, ob man einen PHP-Builder (oder ein sonstiges grafisches Tool) braucht, wenn man mit Beans arbeitet. Aber das wurde schon beantwortet

Hey, toll. Nach ein paar Startschwierigkeiten ist doch noch etwas aus diesem Thema geworden :applaus:
Thanks all, ganz besonders Ebenius.
Kann man auf "gelöst" setzen.
EDIT: Ich glaub, das Thema hat ein paar Sternchen verdient, oder? Sind doch gute Allgemeininfos zu Beans darin.

 

[Ebenius]

Kann man auf "gelöst" setzen.

Hab ich gemacht, das nächste mal kannst Du's selber: http://www.java-forum.org/java-faq-...ann-ich-ein-thema-als-erledigt-markieren.html

Ebenius

 

[André Uhres]

Ausserdem: XMLEncoder funktioniert nur mit Beans ( Beispiel: DynamicArray - Byte-Welt Wiki ).