Beans Erklärung

[DerEinzigartige]

Hi,

überall wird von diesen "Beans" gesprochen. Natürlich hab ich mal danach gegoogled, aber die Erklärungen finde ich doch zu theoretisch.

Also laut der ganzen Seiten sind Beans Klassen, die nach einer bestimmten Konvention entwickelt wurden und deren Objekte sich somit komplett in einer GUI änderbar sind und sich in ihrem Zustand abspeichern lassen.

Fragen: Wäre jetzt diese (schnell aus dem Ärmel geschüttelt), bis auf die Serialisierbarkeit, somit ein Bean? Wenn nein, was fehlt/was ist falsch?

public class Customer {
	private String id;
	private String lastName;
	private String firstName;
	private String street;
	private String postalCode;
	private String town:
	private double balance;

	public void writeIntoDatabase() {
		// ... Methode zum Speichern der Eigenschaften des Objektes in eine Datenbank
	}

	public String getID() {
		return id;
	}

	public void setID(String id) {
		this.id = id;
	}

	// getter/setter für den rest
	// ..
	
}

 

[nrg]

also ich würde jetzt meine Hand nicht dafür ins Feuer legen, dass das zwingend erforderlich ist aber ich würde:

public String getId() {
...

und

public void setId(String id) {
...

schreiben.

SOA& Webservices in der Praxis - Google Bücher

hier hab ich eine Kleinigkeit dazu gefunden was zumindest eine XML Serialisierung als Beankonform versteht

 

[DerEinzigartige]

Also mein Lehrer damals hat gemeint, Abkürzungen groß zu schreiben. z.b. wird die Abkürzung XML auch immer komplett groß geschrieben (XMLEncoder z.B.).
Oder ist die Bean-Konvention != allgemein gelehrte Programmier-Konvention?

 

[DerEinzigartige]

public class Customer {

    // properties

    private String id;
    private String lastName;
    private String firstName;
    private String street;
    private String postalCode;
    private String town;
    private double balance;

    // methods

    public void write(File outputFile) throws java.io.FileNotFoundException, java.io.IOException {
        FileOutputStream os = new FileOutputStream(outputFile);
        XMLEncoder encoder = new XMLEncoder(os);
        encoder.writeObject(this);
        encoder.close();
        os.close();
    }

    public void read(File inputFile) throws java.io.FileNotFoundException {
        FileInputStream is = new FileInputStream(inputFile);
        XMLDecoder decoder = new XMLDecoder(is);
        Customer customer = (Customer) decoder.readObject();
        this.equalize(customer);
    }

    public void equalize(Customer customer) {
        setID(customer.getID());
        setLastName(customer.getLastName());
        setFirstName(customer.getFirstName());
        setStreet(customer.getStreet());
        setPostalCode(customer.getPostalCode());
        setTown(customer.getTown());
        setBalance(customer.getBalance());
    }

    public String getID() {
    	return id;
    }

    public void setID(String id) {
        this.id = id;
    }

// Restliche Getter/Setter.....

Wäre die Klasse nun ein Bean?

 

[nrg]

probiers doch mit XML Serialisierung aus. Wenn das Objekt wieder gelesen wird, ist die Klasse wohl beankonform. Ich würde sagen ja...
aber, wie gesagt, bin mir nicht sicher, ob die methoden case sensitive sind und nur der erste Buchstabe der Variablenbezeichnung groß geschrieben wird (und es somit getId() heissen müsste).

 

[DerEinzigartige]

Jub, alles klar, vielen Dank für die Hilfe

 

[Gastredner]

Ich kann mich irren, aber ich meine, eine Bean kann durch vier Dinge identifiziert werden:

1. Sie implementiert das Interface Serializable.
2. Sie bietet PropertyChangeSupport, also die Möglichkeit, einen Listener bei der Änderung eines Wertes über diese Änderung zu informieren.
3. Sie bietet Getter und Setter für alle (serialisierbaren) Attribute an.
4. Sie besitzt einen parameterlosen Standardkonstruktor.

Ob da jetzt eine GUI-Komponente oder sonstwas mit dranhängt - das sollte egal sein.

 

[nrg]

besitzt nicht jede Klasse einen parameterlosen Standardkonstruktor, weil bei der instanziierung der super konstruktor von Object aufgerufen wird?

 

[EdelStoff]

besitzt nicht jede Klasse einen parameterlosen Standardkonstruktor, weil bei der instanziierung der super konstruktor von Object aufgerufen wird?

nur solange bis die Klasse keinen parametrisierter Konstruktor besitzt.

public class A {
	int i;
	public A(int i) {
		this.i = i;
	}
}

public class B {
	public B() {
		A a = new A(); // geht nicht
	}
}

 

[LoR]

Das ist bspw. eine Java-Bean (vgl. Beitrag von "Gastredner"):

import java.beans.*;
import java.io.Serializable;

public class Customer implements Serializable {

    public static final String PROP_LASTNAME = "lastName";

    private PropertyChangeSupport propertyChangeSupport = new PropertyChangeSupport(this);
    
    private String id;
    private String lastName;

    /**
     * Get the value of id
     *
     * @return the value of id
     */
    public String getId() {
        return id;
    }

    /**
     * Set the value of id
     *
     * @param id new value of id
     */
    public void setId(String id) {
        this.id = id;
    }

    /**
     * Get the value of lastName
     *
     * @return the value of lastName
     */
    public String getLastName() {
        return lastName;
    }

    /**
     * Set the value of lastName
     *
     * @param lastName new value of lastName
     */
    public void setLastName(String lastName) {
        String oldLastName = this.lastName;
        this.lastName = lastName;
        propertyChangeSupport.firePropertyChange(PROP_LASTNAME, oldLastName, lastName);
    }

    /**
     * Add PropertyChangeListener.
     *
     * @param listener
     */
    public void addPropertyChangeListener(PropertyChangeListener listener) {
        propertyChangeSupport.addPropertyChangeListener(listener);
    }

    /**
     * Remove PropertyChangeListener.
     *
     * @param listener
     */
    public void removePropertyChangeListener(PropertyChangeListener listener) {
        propertyChangeSupport.removePropertyChangeListener(listener);
    }
}

Entscheidend an einer Javabean ist vor allem, dass die Getter/Setter einer bestimmten Namenskonvention folgen. PropertyChangeSupport und Serializeable muss eine Bean nicht unbedingt haben/sein wird aber meistens vorausgesetzt.

 

[Gelöschtes Mitglied 5909]

Gastredner und Lor haben schon das wesentlich geschrieben.

Siehe auch:

JavaBeans ? Wikipedia

etwas wichtiges haben sie aber noch vergessen:

Beans sind Datenkontainer und sollten deshalb keine Logik enthalten.

also hat writeIntoDatabase() etc. darin nix zu suchen.

 

[Wortraum]

Also mein Lehrer damals hat gemeint, Abkürzungen groß zu schreiben.

Man findet beides, selbst innerhalb der Java-API. Einfach mal zwei beliebige Beispiele aus dem reichhaltigen Angobt der Uneinheitlichkeit herausgegriffen: AclEntry, AWTError. Ich bevorzuge die erste Variante.