Beans (Básico)

Un Bean persiste cuando tiene sus propiedades, campos e informaci�n de estado almacenadas y restauradas desde un fichero. El mecanismo que hace posible la persistencia se llama serializaci�n. Cuando un ejemplar de bean es serializado se convierte en una canal de datos para ser escritos. Cualquier Applet, aplicaci�n o herramienta que utilice el Bean puede "recontistuirlo" mediante la deserializaci�n. Los JavaBeans utilizan el API Object Serialization del JDK para sus necesidades de serializaci�n.

Siempre que una clase en el �rbol de herencia implemente los interfaces Serializable o Externalizable, esa clase ser� serializable.

Todos los Bean deben persisitir. Para persistir, nuestros Beans deben soportar la serializaci�n implementando los interfaces java.io.Serializable o java.io.Externalizable. Estos interfaces te ofrecen la elecci�n entre serializaci�n autom�tica y "hazlo tu mismo".

�Controlar la Serializaci�n

Se puede controlar el nivel de serializaci�n de nuestro Bean.

• Autom�tico: implementando Serializable. Todo es serializado.
• Excluyendo los campos que no se quieran serializar marc�ndolos con el modificador transient (o static).
• Escribir los Beans a un fichero de formato espec�fico: implementando Externalizable, y sus dos m�todos.

�Serializaci�n por Defecto: El Interface Serializable

El interface Serializable proporciona serializaci�n autom�tica mediante la utilizaci�n de las herramientas de Java Object Serialization. Serializable no declara m�todos; act�a como un marcador, dici�ndole a las herramientas de Serializaci�n de Objetos que nuestra clase Bean es serializable. Marcar las clases con Serializable significa que le estamos diciendo a la M�quina Virtual Java (JVM) que estamos seguros de que nuestra clase funcionar� con la serializaci�n por defecto. Aqu� tenemos algunos puntos importantes para el trabajo con el interface Serializable.

• Las clases que implementan Serializable deben tener un constructor sin argumentos. Este constructor ser� llamado cuando un objeto sea "reconstituido" desde un fichero .ser.
• No es necesario implementar Serializable en nuestra subclase si ya est� implementado en una superclase.
• Todos los campos excepto static y transient son serializados. Utilizaremos el modificador transient para especificar los campos que no queremos serializar, y para especificar las clases que no son serializables.

El BeanBox escribe los Beans serializables a un fichero con la extensi�n .ser.

El Bean OurButton utiliza la serializaci�n por defecto para conseguir la persistencia de sus propiedades. OurButton s�lo a�ade Serializable a su definici�n de clase para hacer uso de la serializaci�n por defecto.

   public class OurButton extends Component implements Serializable,...

Si arrastramos un ejemplar de OurButton al BeanBox, la hoja de propiedades muestra las propiedades de OurButton. Lo que nos asegura que la serializaci�n est� funcionando.

1. Cambia algunas de las propiedades de OurButton. Por ejemplo cambia el tama�o de la fuente y los colores.
2. Serializa el ejemplar de OurButton modificado seleccionando el men� File|SerializeComponent... del BeanBox. Apareceza un dialogo para guardar el fichero.
3. Pon el fichero .ser en un fichero JAR con un manifiesto adecuado.
4. Limpia el BeanBox seleccionando el men� File|Clear.
5. Recarga el ejemplar serializado el men� File|LoadJar.

El ejemplar OurButton aparecer� en el BeanBox con las propiedades modificadas intactas. Implementando Serializable en nuestra clase, las propiedades primitivas y los campos pueden ser serializados. Para miembros de la clase m�s complejos se necesita utilizar t�cnicas diferentes.

�Serializaci�n Selectiva Utilizando el Modificador transient

Para excluir campos de la serializaci�n de un objeto Serializable, marcaremos los campos con el modificador transient.

  transient int Status;

La serializaci�n por defecto no serializa los campos transient y static.

�Serializaci�n Selectiva: writeObject y readObject()

Si nuestra clase serializable contiene alguno de los siguientes m�todos (las firmas deben ser exactas), el serializaci�n por defecto no tendr� lugar.

private void writeObject(java.io.ObjectOutputStream out)
    throws IOException;
private void readObject(java.io.ObjectInputStream in)
    throws IOException, ClassNotFoundException;

Se puede controlar c�mo se serializar�n los objetos m�s complejos, escribiendo nuestras propias implementaci�n de los m�todos writeObject() y readObject(). Implementaremos writeObject cuando necesites ejercer mayor control sobre la serializaci�n, cuando necesitemos serializar objetos que la serializaci�n por defecto no puede manejar, o cuando necesitamos a�adir datos a un canal de serializaci�n que no son miembros del objeto. Implementaremos readObject() para recronstruir el canal de datos para escribir con writeObject().

�Ejemplo: el Bean Molecule

El Bean Molecule mantiene un n�mero de versi�n en un campo est�tico. Como los campos est�ticos no son serializables por defecto, writeObject() y readObject() son implementados para serializar este campo. Aqu� est�n las implementaciones de writeObject() y readObject() de Molecule.java.

private void writeObject(java.io.ObjectOutputStream s)
                        throws java.io.IOException {
        s.writeInt(ourVersion);
        s.writeObject(moleculeName);
    }

private void readObject(java.io.ObjectInputStream s)
                        throws java.lang.ClassNotFoundException,
                               java.io.IOException {
        // Compensate for missing constructor.
        reset();
        if (s.readInt() != ourVersion) {
            throw new IOException("Molecule.readObject: version mismatch");
        }
        moleculeName = (String) s.readObject();
    }

Estas implementaciones l�mitan los campos serializados a ourVersion y moleculeName. Ning�n otro dato de la clase ser� serializado.

Es mejor utilizar los m�todos defaultWriteObject() y defaultReadObject de ObjectInputStream antes de hacer nuestras propias especificaciones en el canal de escritura. Por ejemplo.

private void writeObject(java.io.ObjectOutputStream s)
                        throws java.io.IOException {
        //First write out defaults
        s.defaultWriteObject();
        //...
    }

private void readObject(java.io.ObjectInputStream s)
                        throws java.lang.ClassNotFoundException,
                               java.io.IOException {
        //First read in defaults
        s.defaultReadObject();
        //...
    }

�El Interface Externalizable

Este interface se utiliza cuando necesitamos un completo control sobre la serializaci�n de nuestro Bean (por ejemplo, cuando lo escribimos y leemos en un formato de fichero espec�fico). Necesitamos implementar dos m�todos: readExternal() y writeExternal(). Las clases Externalizable tambi�n deben tener un constructor sin argumentos.

�Ejemplo: Los Beans BlueButton y OrangeButton

Cuando ejecutamos BeanBox, podemos ver dos Beans llamados BlueButton y OrangeButton en el ToolBox. Estos dos Beans son realmente dos ejemplares serializados de la clase ExternalizableButton.

ExternalizableButton implementa el interface Externalizable. Esto significa que hace toda su propia serializaci�n, mediante la implementaci�n de Externalizable.readExternal() y Externalizable.writeExternal().

El programa BlueButtonWriter es utilizado por los makefile de los botones para crear un ejemplar de ExternalizableButton, cambiar su propiedad background a azul, escribir el Bean en un fichero BlueButton.ser. OrangeButton se crea de la misma manera, utilizando OrangeButtonWriter. El makefile pone estos ficheros .ser en buttons.jar, donde el ToolBox puede encontrarlos y recontistuirlos.