JavaBeans was ist daran so aussergewoehnlich

[Jay1980]

Servus, ich verstehe nicht was an JavaBeans so toll ist, im EE-Umfeld bieten EJBs ja tolle Zusatzeffekte, aber ich sehe im SE-Umfeld nur die Vereinbarung: Default-Konstruktor und getter- und setter- und schon haben wir eine Softwarekomponente ?! Danke vorab für etwas Aufklärung - Inselauszug habe ich überflogen, aber die Kerngedanken kann ich da nicht nachvollziehen, also was der Beeeeeef der Beans ist: Galileo Computing :: Java ist auch eine Insel - 10 Architektur, Design und angewandte Objektorientierung

 

[maki]

JavaBeans != EnterpriseJavaBeans

Ansosnten finde ich die Wortwahl in dem Link sehr schlecht, "Komponeneten" sind was anders, JavaBeans sind Datenstrukturen,keine richtigen Objekte.

 

[nillehammer]

Man wollte man einen standardisierten (oder besser konventionellen) Weg, um Instanzen von Datenklassen zu erzeugen, Werte in ihnen zu speichern und wieder auszulesen. Darum herum haben sich dann verschiedenste Templatesprachen entwickelt, wo man mit bestimmten Konstrukten auf den Wert zugreifen und direkt in der GUI anzeigen kann, z.B. so ${meineBean.variablenWert}
Intern hat das GUI-Framework daraus bei der Anzeige den getter-Aufruf oder bei der Eingabe den setter-Aufrufgemacht. Viele Frameworks (die meisten GUI-Frameworks, Hibernate usw.) machen von dieser Konvention heftigsten Gebrauch.

Mit dem Aufkommen von DI-Containern á la Spring, AOP-Frameworks und ByteCode-Instrumentierung ist die Bean-Konvention aber nicht mehr so entscheidend. Und im Zusammenhang mit ihren Nachteilen (ich mag keine public Konstruktoren) ist Deine Frage darum durchaus berechtigt.

 

[Andgalf]

(ich mag keine public Konstruktoren)

Warum das denn nicht?

Mich nervt es, dass der Default Konstruktor public sein muss. Aber bei allen anderen Konstruktoren ??

 

[nillehammer]

Warum das denn nicht?

- Ich arbeite sehr gerne mit sprechenden Methodennamen. Darum schreibe ich meist statische Factory-Methoden (createDefault, createWithParent oder sowas). Oder je nach Anwendungsfall auch builder-Methoden. Wenn ich diese Methoden habe, soll der Nutzer meiner API gezwungen sein, sie zu verwenden. Deswegen Konstruktor nur package-private oder protected, wenn die Klasse vererbbar sein soll.
- (Fast) immer mache ich bei meinem API die Funktionalität über Interfaces zugänglich. Über das Erzeugen und Ausliefern der Implementierung habe ich gerne selbst die Kontrolle. Das treibe ich soweit, dass ich nicht nur die Sichtbarkeit der Konstruktoren einschränke, sondern sogar der Implementierungsklassen selbst.

 

[maki]

Ich sehe da kein Problem wenn es sich nur um Datenstrukturen handelt, wie JavaBeans zB., denn da der der Nutzer (=Entwickler) jederzeit kaputte "Instanzen" erstellen.

Wie gesagt, JavaBeans sind "dumme" Datenstrukturen ohne verhalten, keine Objekte im eigentlichen Sinne (Zustand + Verhalten), bei JavaBeans tut man sich sehr schwer wenn man versucht Regeln aus der OOP anzuwenden/einzuhalten.

 

[Andgalf]

Ich sehe da kein Problem wenn es sich nur um Datenstrukturen handelt, wie JavaBeans zB., denn da der der Nutzer (=Entwickler) jederzeit kaputte "Instanzen" erstellen.

Wie gesagt, JavaBeans sind "dumme" Datenstrukturen ohne verhalten, keine Objekte im eigentlichen Sinne (Zustand + Verhalten), bei JavaBeans tut man sich sehr schwer wenn man versucht Regeln aus der OOP anzuwenden/einzuhalten.

Ja aber oft gibt es da Konflikte ... In den Entities finde ich es oft nützlich, wenn der Default Konstruktor nicht sichtbar ist. Weil ich eben verhindern will, dass da kaputte Instanzen erstellt werden.

Jetzt kann es aber sein, dass ich i-wo ein Framework verwende JSF oder Dozer oder was auch immer, wass mich dazu zwingt die Beans Konventionen einzuhalten.

Das nervt mich schon etwas

 

[maki]

Ja aber oft gibt es da Konflikte ... In den Entities finde ich es oft nützlich, wenn der Default Konstruktor nicht sichtbar ist. Weil ich eben verhindern will, dass da kaputte Instanzen erstellt werden.

JPA Entities nüssen nicht JavaBEan konform sein, ein protected default Constructor reicht (grundsätzlich könnte das ORm Framework auch einen einfügen), aber die restlichen JavaBean Konventionen müssen nicht eingehalten werden.

Jetzt kann es aber sein, dass ich i-wo ein Framework verwende JSF oder Dozer oder was auch immer, wass mich dazu zwingt die Beans Konventionen einzuhalten.

Nun, Dozer übersetzt JavaBeans in JavaBeans, JSF setzt JavaBeans voraus...

D.h. aber nicht dass du deine Entities zB. direkt in JSF nutzen musst, ist halt mehr Aufwand nötig, baer wer hat auch gesagt das man alles ganz eifnach bekommt?

 

[Andgalf]

wer hat auch gesagt das man alles ganz eifnach bekommt?

Lach niemand hat das gesagt .... aber ich mags nun mal einfach

 

[Jay1980]

Ich sehe da kein Problem wenn es sich nur um Datenstrukturen handelt, wie JavaBeans zB., denn da der der Nutzer (=Entwickler) jederzeit kaputte "Instanzen" erstellen.

Wie gesagt, JavaBeans sind "dumme" Datenstrukturen ohne verhalten, keine Objekte im eigentlichen Sinne (Zustand + Verhalten), bei JavaBeans tut man sich sehr schwer wenn man versucht Regeln aus der OOP anzuwenden/einzuhalten.

Moment, heisst das etwa, dass eine JavaBean keine Methoden haben darf, ausser die Accessoren?

 

[Andgalf]

Moment, heisst das etwa, dass eine JavaBean keine Methoden haben darf, ausser die Accessoren?

Nein das heißt es nicht. Aber wenn man JavaBeans alls "dumme" Datenstruktur betrachtet wäre es halt unsauber logik(Verhalten) in die Beans zu schreiben.

 

[maki]

Moment, heisst das etwa, dass eine JavaBean keine Methoden haben darf, ausser die Accessoren?

Accessoren und mutatoren für jede Instanzvariable brechen Kapselung und informaitonhiding, also Grundlegende OOP Konzepte, du kannst natürlich soviel andere Methoden haben wie du willst, aber OO wird das ganze nicht mehr dadurch...

Es verwirrt Leute nur wenn sie versuchen OOP Konzepte in nicht OOP Datenstrukturen zu quetschen, ist ja auch klar warum