Significato della tecnologia JavaBeans

Cioè perché esistono i JavaBeans?

Premessa

In Java un oggetto descrive la sua interfaccia chiamando delle funzioni (di solito) nel suo costruttore per:

• creare componenti: mioBottone = new JButton("Bottone");
• modificare le proprietà mioBottone.setFont(new Font("Serif", Font.BOLD, 14));
• assegnargli una posizione mioPanel.add(mioBottone);

(Questo solo per descrivere la rappresentazione grafica, poi ci sarà dell'altro codice per la semantica.)

Non è necessario un costruttore

• Per istanziare un oggetto si usa:

  SLIM mioSLIM = new SLIM(args, "CORBA_GlobalSchema");

• Per un JavaBean invece si può anche usare:

  SLIM mioSLIM=null;
  try {
    mioSLIM = (SLIM)java.beans.Beans.instantiate(null, "SLIM");
  } catch (Exception e) { }

Quindi ci sono 3 modi per costruire un oggetto SLIM:

• Costruttore con paramentri:

  public SLIM(String[] as, String CORBA_GSN) {
    args = as;
    CORBA_GSName = CORBA_GSN;
    initCORBA(); //inizializza oggetti CORBA
    initComponets(); //crea componenti grafici
  }

• Costruttore senza parametri (usa valori di default):

  public SLIM() {
    args = new String[] {"-ORBInitialHost", "sparc20.dsi.unimo.it"
  		, "-ORBInitialPort", "1050"};
    CORBA_GSName = "CORBA_GlobalSchema";
    initCORBA();
    initComponets();
  }

• Funzione di lettura usata dalla deserializzazione:

  private void readObject(java.io.ObjectInputStream in)
  throws IOException, ClassNotFoundException {
    in.defaultReadObject();
    initCORBA(); //gli oggetti CORBA si considerano transienti e vanno riottenuti
  }

args e CORBA_GSName sono ripristinati come erano stati impostati precedentemente. Da notare che in quest'ultimo caso non viene chiamata la funzione per creare i componenti grafici perché vengono ricostruiti dalla deserializzazione così come erano stati salvati.

Dunque, visto che instantiate cerca prima il file .ser, dopo che si è fornito questo file non è più necessaria la funzione che crea gli oggetti grafici.

Il BeanBox lavora in questo modo: permette di creare visivamente i componenti, poi li serializza. In questo modo mantengono tutte le proprietà e la posizione che avevano.

In pratica questo è un utilizzo improprio della persistenza. Per persistenza significa salvare lo stato dell'oggetto, per esempio a SLIM basterebbe salvare i significati scelti, perché le altre informazioni possono essere ricostruite. In questo caso invece, il fatto importante è salvare i componenti grafici invece di ricrearli.

Ci sono molte analogie con Visual Basic (o simili), anche lì ci sono 2 componenti: un tipo di file per il codice, ed uno per le form, cioè per la descrizione dell'interfaccia. Quest'ultimo file si può modificare solo visualmente, i componenti grafici hanno le stesse caratteristiche che a run-time, le modifiche alle proprietà avvengono interattivamente e quando si salva viene serializzato.

I JavaBean sono talmente uguali a Visual Basic che tramite un ActiveX Bribge si può inserire un JavaBean in una form di Visual Basic perché il meccanismo di serializzazione è compatibile con quello (trasparente) di Visual Basic.

Quindi il vantaggio dei JavaBean è che possono essere utilizzati in tool di sviluppo visuale che salvano il lavoro tramite la serializzazione. Tool che sollevano il programmatore dal dover scrivere del codice per descrivere i componenti visuali.

Riassumendo:

1. Il JavaBean viene aggiunto al ToolBox
2. Si collegano gli eventi
3. Si modificano le proprietà
4. Si esegue come a run-time
5. Si salva il risultato

Questo vantaggio può essere ottenuto, però, anche tramite ambienti di sviluppo che non usano la serializzazione, ma generano il codice al volo (vedi Forte4j). Cioè se, per esempio, viene modificato il font di una JLabel nella funzione initComponets() viene aggiunta la riga jlblCurrentTime.setFont(new Font( … ; mentre utilizzando la tecnica sopra descritta non verrebbe aggiunto nessun codice, ma cambiata la proprietà font alla JLabel, proprietà che fa parte del suo stato e viene salvata, per essere ripristinata uguale.