Java beans Universidad de Salamanca.pdf

Introducción a Javabeans Mayo, 2003

Introducción a los JavaBeans

David Sierra Sánchez Jesús F. Rodríguez Aragón

Información de los autores:

David Sierra Sánchez

Alumno de 3º de Ingeniería Técnica de Informática de Sistemas

Facultad de Ciencias-Universidad de Salamanca

Plaza de la Merced S/N – 37008- Salamanca

Jesús F. Rodríguez Aragón

Alumno de 3º de Ingeniería Técnica de Informática de Sistemas

Facultad de Ciencias-Universidad de Salamanca

Plaza de la Merced S/N – 37008- Salamanca

Este documento puede ser libremente distribuido.

© 2003 Departamento de Informática y Automática – Universidad de Salamanca.

Introducción a Javabeans i

RESUMEN:

Este trabajo tiene como objetivo de realizar una breve introducción a los componentes

JavaBeans para la asignatura Programación Orientada a Objetos del curso 3º de Ingeniería

Técnica en Informática de Sistemas (Plan 1997).

JavaBeans es un modelo de componentes que favorece la reutilización y que será

visualizado en un entorno Java. Pero un componente software debe ser independiente del

lenguaje, de la plataforma y basado en un modelo estándar para permitir la correcta interacción

entre los mismos, pero sin violar la encapsulación.

Para dar soporte a estos cuatro requisitos, JavaBeans tiene estas cinco características:

Introspección, gracias a la cuál se permite la interacción entre los componentes; personalización,

que como su nombre indica, proporciona al usuario la posibilidad de elegir como quiere su

Bean; eventos para la comunicación entre Beans; propiedades que definen y diferencian al

Bean; y persistencia, que se encarga de guardar los datos así como de su seguridad.

Introducción a Javabeans ii

TABLA DE CONTENIDOS:

0 Introducción………………………………………………………………………….. 1

0.1 Introducción a Java……………………………………………………………. 1

1 Introducción a JavaBeans…………………………………………………………... 2

2 Introspección……………………………………………………………………….... 3

2.1 Patrones de Propiedades………………………………………………………. 4

2.2 Patrones de Eventos………………………………………………………….... 4

2.3 Patrones de Métodos…………………………………………………………... 5

2.4 Reglas en la “gramática”………………………………………………………. 5

3 Personalización……………………………………………………………………… 5

4 Eventos………………………………………………………………………………. 5

4.1 La clase EventObject………………………………………………………….. 6

4.2 Receptores de Eventos………………………………………………………… 7

4.3 Eventos fuente…………………………………………………………………. 7

4.4 Adaptador de Eventos…………………………………………………………. 8

5 Propiedades………………………………………………………………………….. 8

5.1 Métodos de acceso…………………………………………………………….. 8

5.2 Propiedades simples………………………………………………………….... 9

5.3 Propiedades indexadas……………………………………………………….... 9

5.4 Propiedades ligadas …..………………………………………………...........10

5.5 Propiedades restringidas………………………………………………………10

5.6 Un ejemplo de propiedades ligadas…………………………………………...11

6 Persistencia…….…………………………………………………………………….17

6.1 Serialización…………………………………………………………………. 17

6.2 Versionado…………………………………………………………………….17

6.3 Seguridad………………………………………………………………...……18

Introducción a Javabeans iii

7 Resumen y conclusiones…………………………………………………………….18

8 Referencias…………………………………………………………………………..19

TABLA DE FIGURAS:

Fig 1. Fuente y listeners……………………………………………………………….16

-- 1 --

0. INTRODUCCIÓN:

En la fabricación de software, al igual que en la industria, se busca facilitar el trabajo mediante

la construcción de componentes básicos que, uniéndose, dan como resultado el producto final.

Un ejemplo de esto, enfocado a la informática, lo tenemos en la fabricación de ordenadores:

construcción en serie de microprocesadores, tarjetas de sonido, vídeo, etc.

En el software esto se llama reutilización. En los primeros productos software este

concepto era nulo ya que se programaba para la máquina en la que iba a ser ejecutado, sin

posibilidad de llevarse, dicho programa, a otra y tener la certeza de que iba a funcionar

correctamente. Poco a poco fueron surgiendo diferentes modelos de reutilización, como las

librerías, aunque no resolvieron el problema por completo ya que carecían de flexibilidad (se

podía reutilizar en un mismo proyecto pero sólo en él).

En la búsqueda de mejorar la reutilización software llegamos al concepto de objeto. Con

los objetos nos centramos en las entidades que forman un proyecto siendo, estos componentes,

más genéricos y por tanto haciendo que los objetos sean más sencillos, lo que favorece que sean

reutilizados en proyectos de diversa naturaleza.

Al aparecer Internet, se produce una necesidad, aún mayor, de encontrar un lenguaje

independiente de la plataforma, puesto que hay una interactividad ente ordenadores

independientes unos de otros. JAVA favorecía este avance. Los JAVABEANS favorecen aún

más esta reutilización ya que son componentes muy básicos que siguen un estándar.

0.1. INTRODUCCIÓN A JAVA:

JAVA nació como un lenguaje que facilitase el desarrollo software para dispositivos

electrónicos de bajo precio (relojes...). Con el auge de internet y para demostrar que el lenguaje

se adaptaba a cualquier plataforma se le integró en el interior de un navegador. El resto es

conocido.

Las características principales de JAVA son:

o Independencia de la máquina:

Compilación en el que se generan instrucciones binarias que no tienen nada que ver con

las usadas por ningún procesador, sino a una máquina virtual (bytecode). Para

ejecutarse, se usa un intérprete que traducirá este bytecode a código comprensible por la

máquina.

INTRODUCCIÓN A LOS JAVABEANS

Introducción a Javabeans 2

o Eficacia:

Compilación just-in-time: La máquina virtual va interpretando bytecodes y almacena el

código máquina nativo empleado. Cuando se indica que hay que volver a sobre algo

procesado, no hay que reinterpretar el bytecode.

o Sencillez:

Lenguaje sencillo porque se pensó para componentes electrónicos pequeños. Se

eliminan elementos que no son absolutamente necesarios.

o Seguridad:

En cuanto a fiabilidad, no hace falta preocuparse por la creación y liberación de

recursos. El programador tiene menos responsabilidades.

Se impiden operaciones destructivas. Se analiza el código precompilado asegurando que

se ajusta a las normas del lenguaje.

o Orientación a objetos:

Aborda la resolución del problema de forma metódica y ordenada que facilita su

división y permite de este modo la colaboración de varias personas dentro de un

proyecto.

o Capacidad multiproceso:

Usa hilos o threads que no supone un coste computacional elevado.

o Recogida de basura:

Thread de baja prioridad que examina objetos creados y determina si alguno se ha

dejado de utilizarse, momento en el que se procede a su destrucción.

El código JAVA no precisa ser enlazado para producir un fichero ejecutable. La

compilación genera módulos independientes que el intérprete carga en momentos

necesarios.

1. DEFINICIÓN DE JAVABEANS:

JavaBean es un modelo de componentes software que ofrece flexibilidad y reutilización y que

puede ser visualizado por un lenguaje de programación Java.

Un componente software es una parte básica para la construcción de una aplicación, con las

Sierra y Rodríguez

3 Introducción a Javabeans

siguientes características que lo diferencian del resto del código de un proyecto:

o Independencia de la plataforma

o Independencia del lenguaje

o Encapsulación

o Basados en un modelo estándar permitiendo a los componentes interactuar entre sí.

JavaBeans les da a sus componentes estas propiedades, si bien, como hemos dicho antes,

esta asociado al lenguaje Java. Sin embargo, en la actualidad, la independencia del lenguaje es

prácticamente nula en casi todos los modelos de componentes, existiendo “puentes de

comunicación” entre ellos para facilitar la relación.

El modelo JavaBean cumple las siguientes características:

o Introspección: Debe dar capacidad para que se pueda analizar como trabaja el Bean y

los valores de sus propiedades.

o Personalización: La reutilización hace que un bean pueda formar parte de muchas

aplicaciones, pero llegada la hora, en cada una de ellas el diseñador-usuario podrá

cambiar su aspecto y conducta. Se trata de favorecer estos cambios.

o Eventos: Los mensajes que se pasan entre los diferentes beans, diferenciando entre los

que originan dicho evento y los que esperan por él para realizar alguna acción.

o Propiedades: Definen al bean y su apariencia. Pueden ser públicos y privados. Todas

las propiedades públicas han de tener dos métodos de acceso: uno de lectura y otro de

escritura. Esto es una característica de un bean que lo diferencia de cualquier otra clase.

o Persistencia: Debe proporcionar alguna forma para guardar y restaurar el estado del

bean cuando se cierra la aplicación de la que forma parte.

2. INTROSPECCIÓN:

El modelo basado en componentes debe dar la capacidad, al proyecto en el que trabajamos, de

ser reconocido por una persona ajena al mismo. Es decir, que cuando esta persona eche un

vistazo más o menos detallado al código, reconozca su funcionamiento.

En un entorno orientado a objetos esta característica se complica un poco. Es verdad que

las clases están bien definidas y se reconocen a simple vista, pero los métodos no son tan fáciles



de identificar ya que existe herencia y polimorfismo que complica la vida a un nuevo

desarrollador que entre en un proyecto ya avanzado.

JavaBeans aporta unas sofisticadas características de introspección mediante el uso de

mecanismos implícitos y explícitos. Así, las clases dan una serie de especificaciones explícitas y

unos patrones para el diseño de sus propiedades. Los eventos y los métodos proporcionan

especificaciones implícitas.

Pero ¿en qué consisten estos mecanismos y cómo se consiguen?, JavaBeans aporta una

terminología y una sintaxis estándar a la hora de nombrar o llamar a los métodos, clases,

eventos, etc. Esto es lo que se conoce como patrones de diseño.

2.1. PATRONES DE PROPIEDADES:

Las propiedades son las características que tomarán los objetos de una clase o bean, que se

prestan para la obtención y asignación de valores, normalmente realizadas, estas operaciones,

por un método. La regla formal para patrones de diseño de propiedades es desarrollar métodos

de la siguiente forma:

public <TipoPropiedad> get<NombrePropiedad>();

public void set<NombrePropiedad>(int e, <TipoPropiedad> p);

Como métodos de obtención y asignación respectivamente.

2.2. PATRONES DE EVENTOS:

Hay dos tipos de eventos como se explicará más adelante: los multicast y los unicast. Los

primeros son aquéllos que van a ser recibidos por varios receptores, valga la redundancia, y los

segundos son aquéllos que sólo tienen un único receptor como destino.

Así, los patrones de diseño para los multicast usan los siguientes métodos para detectar

dichos eventos:

public void add<EventListenerType>(<EventListenerType> e);

public void remove<EventListenerType>(<EventListenerType> e);

Para añadir o borrar un campo de la lista de receptores que recibirán un determinado

evento. Si nos referimos a los unicast se detectará que el método

add<EventListenerType>Listener() lanza una excepción llamada

java.util.TooManyListenersException (Se explicará más adelante).

Sierra y Rodríguez


2.3. PATRONES DE MÉTODOS:

Los métodos se definen como externos o públicos del bean. Entre los públicos se incluyen los

métodos vistos en los dos apartados anteriores.

2.4. REGLAS EN LA “GRAMÁTICA”:

La nomenclatura utilizada en Java es la usada aquí. La primera letra de todas las palabras

en los nombres de clases aparece en mayúsculas. En los nombres de métodos y propiedades

todas, menos la primera palabra, tienen su primera letra en mayúsculas.

Los nombres que incluyan acrónimos mantienen las mayúsculas del mismo y los campos

enumerados o constantes se muestran en mayúsculas.

3. PERSONALIZACIÓN:

Los beans pueden ser aplicaciones personalizables. El API de bean incluye clases e interfaces

para personalizar en tiempo de diseño y en tiempo de ejecución. Se pueden personalizar sus

propiedades. Las propiedades con tipos de datos simples no tienen problema, en cambio hay

otro tipo de propiedades más complejas que se entrecruzan y que necesitan, para ser

personalizadas, un editor de propiedades que nos ayude a tal tarea.

4. EVENTOS:

Los beans deben entenderse entre sí de alguna forma, debe haber comunicación entre ellos para

que la aplicación que forman realice su determinada misión. Los eventos son como los mensajes

de C++ para la comunicación entre los objetos. JavaBeans sigue el modelo de eventos de Java.

En Java hay que diferenciar entre un modelo antiguo de eventos, ya obsoleto, y otro

modelo más moderno y actual que es el que sigue JavaBeans.

En el modelo antiguo la clase utilizaba una sentencia switch para capturar los eventos

que le interesaban. Así, si no se utilizaba un determinado evento dentro de una clase, se enviaba

a la clase padre para que ésta lo manejase y así sucesivamente siguiendo la jerarquía de clases.

Por esto se hacia muy ineficiente ya que todos los objetos recibían notificación de un evento sin

saber si les iba a interesar o no. Además es un modelo con poca flexibilidad ya que debemos

generar eventos específicos para un determinado componente, cuando lo ideal sería que hubiese



un único evento para una determinada acción y que éste pudiese llegar a cualquier tipo de

componente.

El nuevo modelo de eventos introduce los eventos fuente y receptores. Así, un bean que

genera eventos es una fuente de eventos. Pero además éste proporciona métodos a través de los

cuales los beans receptores se pueden registrar como eventos receptores. Así, cuando sucede un

evento, el bean fuente notifica a todos (esto no siempre es así, como se verá después) los

eventos receptores registrados.

4.1. LA CLASE EVENTOBJECT:

Este nuevo modelo de eventos posee una clase raíz llamada EventObject de la que derivan

todos los demás componentes. Así podremos crear eventos específicos para el bean que

queramos, únicamente derivando una de las clases basadas en EventObject y definiendo sus

propiedades y métodos de acceso para ese evento.

Aquí se muestra la jerarquía de clases de eventos:

clase java.awt.event.EventObject

clase java.awt.AWTEvent

clase java.awt.event.ActionEvent

clase java.awt.event.AdjustementEvent

clase java.awt.event.ComponentEvent

clase java.awt.event.ContainerEvent

clase java.awt.event.FocusEvent

clase java.awt.event.InputEvent

clase java.awt.event.KeyEvent

clase java.awt.event.MouseEvent

clase java.awt.event.PaintEvent

clase java.awt.event.WindowsEvent

clase java.awt.event.ItemEvent

clase java.awt.event.TextEvent

Sierra y Rodríguez


clase sunw.util.EventObject

clase java.beans.PropertyChangeEvent

En una breve explicación de la jerarquía se dirá que todos los eventos del AWT (Kit

abstracto de gestión de ventanas) derivan de la clase java.awt.AWTEvent. El AWT es el gestor

que ofrece Java cuando nos referimos a gráficos y GUI (Interfaz gráfica de Usuario).Por

ejemplo, dentro de ella se manejan automáticamente los movimientos y cambios de tamaño de

componentes para que la GUI funcione bien sin importar si un programa está recibiendo esos

eventos. Estos están recogidos dentro de la clase java.awt.event.ComponentEvent. Otros eventos

que se recogen son los que tienen que ver con el teclado (java.awt.event.KeyEvent) o el ratón

(java.awt.event.MouseEvent). Otras dos clases importantes son sunw.util.EventObject que

proporciona compatibilidad con versiones anteriores y java.beans.PropertyChangeEvent que se

genera cuando un bean cambia sus propiedades ligadas o restringidas.

4.2. RECEPTORES DE EVENTOS:

Son usados por los objetos interesados para capturar eventos y se implementarán como

interfaces, no como clases y realizarán tareas específicas cada vez que se reciba un evento.

4.3. EVENTOS FUENTE:

Como se ha dicho son aquéllas que se encargan de mandar el evento, pero a parte de esto se

debe proporcionar un mecanismo para que los objetos interesados en recibir un determinado

evento se registren como receptores. Así, siguiendo las convenciones de nomenclatura nos

encontramos con dos métodos, uno de adición y otro de eliminación:

public void addSignalRcvdListener (SignalRcvdListener 1);

public void removeSignalRcvdListener (SignalRcvdListener 1);

Lo que hace el método de adición (el primero) es incluir una interfaz receptora a la lista de

receptores que posee el evento fuente para saber que objetos deben recibir la notificación

cuando suceda el evento en particular. El método de eliminación (el segundo) elimina un

receptor de dicha lista. Pero se puede dar el caso de que se añada un receptor dos veces o que se

intente borrar un receptor ya eliminado. Estos casos son dependientes de la implementación del

programador, al igual que el orden del reparto de eventos.



Se puede restringir el envío de señales a un solo receptor. Para ello se debe generar una

excepción java.util.TooManyListenerException en el método de adición de receptores. Así se

limita la fuente para que se registre únicamente un receptor, teniendo en cuenta que a los

receptores que se intenten registrar después de que haya otro registrado se les denegará su

solicitud. Cuando se dé el evento en cuestión sólo recibirá notificación el único receptor de la

lista.

4.4. ADAPTADOR DE EVENTOS:

Objeto que se sitúa entre un evento fuente y otro receptor y que toma los eventos antes de que le

lleguen a este último para luego trasladárselos en combinaciones especiales o bien cuando se

den unas determinadas condiciones.

5. PROPIEDADES:

Las propiedades de un objeto determinan su estado y lo diferencian del resto. Aparecen siempre

en cualquier lenguaje orientado a objetos, pero en JavaBeans son además una parte importante.

Pero ¿por qué son tan importantes?, porque representan el estado del bean. Estado que debe ser

conocido para que se configuren sus características así como para que sus cambios se transmitan

a otros beans. Hay ocasiones en las que no se puede, ni tampoco interesa, cambiar ni examinar

el valor de ciertas propiedades.

Dados varios beans, es tarea del diseñador conectar los beans y construir una aplicación

coherente. Para ello es necesario que conozca sus propiedades y que se ajuste a las necesidades

de la aplicación completa.

Surge ahora un problema, cómo se lleva a cabo toda esta tarea compleja de manipulación

de propiedades. La respuesta a esta pregunta está en los métodos de acceso, las propiedades

simples, indexadas, ligadas y restringidas.

5.1. METODOS DE ACCESO:

Es la forma más sencilla para cambiar la propiedad. Es como utilizar la operación asignación, a

pesar de que sólo funciona si la propiedad es pública. Aspecto importante, y en el que se basan

estos métodos, es que los datos y los detalles de implementación están ocultos ya que la

orientación a objetos sigue el principio de ocultación de la información. Los dos tipos de

Sierra y Rodríguez


métodos de acceso son

o getter o método de obtención: el tipo TipodePropiedad puede variar en función de la

propiedad, si es sencilla (enteros o flotantes) o si es compleja (clase). Su sintaxis

general es:

TipodePropiedad getPropiedad();

o setter o método de asignación: Se encarga de fijar el valor de una propiedad dada. En su

sintaxis general, Propiedad es el nombre de la propiedad cuyo valor se quiere asignar.

Estos métodos tienen una ventaja, y es la validación, es decir, que permiten comprobar

un valor antes de asignarlo a una propiedad, de esta manera aumenta la robustez de la

aplicación. La sintaxis general es:

void setPropiedad (TipodePropiedad valor);

5.2. PROPIEDADES SIMPLES

Son las propiedades que representan un único valor. Por ejemplo, suponiendo una clase Botón,

las propiedades simples o sencillas podrían ser: tamaño, color de fondo, etiqueta

del botón, etc.

5.3. PROPIEDADES INDEXADAS:

Además de las propiedades de valores únicos, JavaBeans ofrece este tipo de propiedades muy

similares a las matrices. Los elementos de la propiedad tienen todos el mismo tipo y se acceden

mediante un índice entero. Se puede acceder a ellas mediante los métodos de acceso que

variarán de los explicados antes, ya que cada propiedad es sólo accesible a través de su índice.

El primer método permite asignar u obtener el valor de la propiedad especificada por un

índice. En su sintaxis general Propiedad hace referencia a la propiedad cuyo valor se quiere

asignar u obtener Si el índice esta fuera de la matriz se generará una excepción en tiempo de

ejecución:

void setPropiedad (int index, TipodePropiedad valor);

TipodePropiedad getPropiedad();



El segundo método permite asignar u obtener todos los valores de una propiedad indexada.

Al asignar la propiedad indexada se podrá cambiar el tamaño de la matriz que contiene los

índices:

void setPropiedad (TipodePropiedad valor[]);

TipodePropiedad[] getPropiedad();

5.4. PROPIEDADES LIGADAS:

Aquéllas que cuando cambian notifican a todas las partes interesadas la naturaleza del cambio.

Pero que quede bien claro que sólo informan a aquellas propiedades interesadas y sólo a ellas,

no a todas.

El mecanismo en el que se basan es el siguiente: Es sencillo, existe un bean fuente que

mediante un evento notifica a un bean receptor cuando se produzca un cambio en la propiedad

ligada. Debe quedar bien claro que estas propiedades no son bidireccionales y que por tanto los

receptores no pueden contestar.

Para que el bean dé soporte a propiedades ligadas, debe soportar dos métodos usados para

registrar los bean interesados en el cambio de propiedad (uno para adición y otro para

eliminación):

public void addPropertyChangeListener(PropertyChangeListener

x);

public void removePropertyChangeListener(PropertyChange

Listener x);

Y así funciona: Un bean A está interesado en una propiedad ligada del bean B. A llama al

método addPropertyChangeListener() proporcionado por el bean B y le pasa una instancia de

la interfaz PropertyChangeListener. Cuando sucede un cambio en la propiedad ligada del B este

llama al método propertyChange() de todas las interfaces registradas notificando el cambio a

todos los beans interesados. La notificación es sencillamente un objeto PropertyChangeEvent

que encapsula la propiedad que ha cambiado (su viejo valor y su nuevo valor). Se llamará fuente

al bean que tiene la propiedad ligada y receptor al que recibe la notificación de los cambios.

5.5. PROPIEDADES RESTRINGIDAS:

Buscan la aprobación de otros beans antes de cambiar su valor. Al igual que para las

Sierra y Rodríguez


propiedades ligadas se deben proporcionar dos métodos de registro para los receptores:

public void addVetoableChangeListener(VetoableChangeListener

x);

public void removeVetoableChangeListener(VetoableChange

Listener x);

Las partes interesadas en la validación de cambios en una propiedad restringida se registran

con addVetoableChangeListener() y pasan junto con ellas una instancia de la interfaz

VetoableChangeListener. Cuando una propiedad restringida cambia, el bean poseedor llama al

método vetoableChange() para todas las interfaces VetoableChangeListener que haya

registradas con el bean. Se pasará a todas ellas una copia del objeto PropertyChangeEvent, ya

comentado antes. En este momento los receptores deben decidir si aprueban el cambio o no. Si

es el segundo caso se generará una excepción PropertyVetoException. El bean que tiene la

propiedad restringida captura la excepción y asigna a la propiedad el valor anterior sin tener que

notificar a todas las partes interesadas el nuevo cambio de valor.

Tanto en las propiedades ligadas como en las restringidas, es posible que un receptor se

registre a sí mismo, en este caso el bean proporciona los siguientes métodos específicos:

public void add<NombrePopiedad>Listener(VetoableChange

Listener x);

public void remove<NombrePropiedad>Listener(VetoableChange

Listener x);

5.6. UN EJEMPLO DE PROPIEDADES LIGADAS:

Para aclarar más el concepto de propiedad ligada, se supone un ejemplo con dos clases:

Producto y Empleado. Cuando el stock del producto sea menor a cierta cantidad mínima, el

empleado deberá ser notificado para, por ejemplo, hacer un pedido.

El primer paso será crear una clase, que se llamará Producto que tenga incluida la

propiedad ligada, que en este caso será stock:

public class Producto

{

private int stock;

public Producto ( ) {



stock = 0;

}

public void SetStock (int nuevoStock){

stock = nuevoStock;

}

public int GetStock ( ){

return stock;

}

}

Se tienen tres funciones miembro: el constructor, que inicializa el valor de la propiedad

stock a cero, la función getter (GetStock) y la función setter (SetStock).

Se definirá, ahora, una nueva clase (llamada StockEvent) que será la encargada de

definir el suceso, también llamado evento. Un suceso o evento es un objeto que se encarga de

notificar algún cambio o alguna acción producida durante la ejecución del programa y, por lo

tanto, se habrá de realizar alguna acción como respuesta. Este suceso deriva de la clase

EventObject y el constructor ha de conocer el objeto fuente y los valores de las propiedades

(que en este caso serán stock_actual y stock_anterior).

import java.util.*;

public class StockEvent extends EventObject

{

protected int anteStock, nuevoStock;

public StockEvent(Object fuente,int anterior, int nuevo){

super (fuente);

nuevoStock = nuevo;

anteStock = anterior;

}

public int GetNuevoStock ( ) {

return nuevoStock;

}

public int GetAnteStock ( ) {

Sierra y Rodríguez


return anteStock;

}

}

Tras crear la clase que define el suceso o evento (en este caso, el suceso será el cambio de

valor de la propiedad stock), se debe crear un interface que declare los métodos que los

objetos interesados en el cambio del valor de dicha propiedad, llamados listeners, han de

implementar.

En este ejemplo, tan sólo se tiene un listener, que será Empleado. La interface declarará

una única función cuyo cuerpo tendrá que ser definido por el objeto interesado en el cambio del

valor de la propiedad stock.

Una interfaz es un tipo especial de clase que únicamente permite indicar la existencia de

métodos que podrán ser implementados por objetos de otras clases.

import java.util*;

public interface StockListener extends EventListener

{

public void enteradoCambioStock (EventObject e);

}

Se ha de guardar de alguna forma, todos los objetos interesados en el suceso (listeners).

Para ello, se creará un array en el que se irán añadiendo y eliminando listeners según vaya

procediendo.

Este array será mantenido por el objeto que posee la propiedad ligada. Así, cuando el

valor de esa propiedad cambie, el objeto fuente informará del cambio a todos los listeners que

se encuentren en ese array. Esto se hará, añadiendo al código que se tiene de la clase

Producto, este otro:

public class Producto

{

...

private Vector stockListeners = new Vector ();

...

...

public synchronized void addStockListener (StockListener



listener) {

stockListeners.addElement (listener);

}

...

public synchronized void removeStockListener

(StockListener listener){

stockListeners.removeElement (listener);

}

...

}

Ahora, en la función SetStock se debe crear un objeto de la clase StockEvent y notificar

el cambio a los listeners de la lista mantenida por el objeto fuente. Para crear este nuevo objeto

de la clase StockEvent se debe pasar como argumentos del constructor el objeto fuente

(this) y los stock_anterior y stock_nuevo.

Para notificar el cambio del valor de la propiedad stock, se llama a la función

notificarCambio a la que se le ha de pasar como argumento únicamente el evento que ha

sido generado.

La función GetStock quedaría así:

public void GetStock (int nuevoStock){

int anteStock = stock;

stock = nuevoStock;

if (anteStock != nuevoStock){

if (nuevoStock < VALOR_MINIMO){

StockEvent event = new StockEvent (this, anteStock,

nuevoStock);

notificarCambio (event);

}

}

}

La función notificarCambio será la encargada de indicar a los objetos interesados

(listeners) que el valor de la propiedad Stock ha sido modificado. Además, si se observa el

código escrito anteriormente, sólo se llamará a esta función cuando el cambio en el valor de la

Sierra y Rodríguez


propiedad Stock, de como resultado un valor por debajo de un cierto valor mínimo (impuesto

por el usuario, por ejemplo).

En el cuerpo de la función notificarCambio, lo primero será hacer una copia de la

lista de listeners. Nadie podrá acceder a esa lista mientras se esté efectuando la copia. Para ello

se utiliza la palabra reservada synchronized. Después, todos los objetos pertenecientes a esa

lista llamarán a la función declarada en el interface: enteradoCambioStock. Así la función

notificarCambio queda de la siguiente manera:

private void notificarCambio (StockEvent event){

Vector lista;

synchronized (this){

lista = (Vector)StockListeners.clone();

}

for (int i=0;i<lista.size();i++){

StockListener listener=(StockListener)lista.ElementAt(i);

listener.enteradoCambioStock (event);

}

}

Una vez que se ha definido la clase fuente y la interfaz, se ha de definir cada uno de los

listeners (en este caso uno exclusivamente) que implementarán esa interface. Se define una

clase Empleado cuyos objetos están interesados en el cambio del valor de la propiedad

stock de cualquier objeto de la clase Producto que implique que valor de stock sea

menor que un cierto valor mínimo, condición que ya se tiene en cuenta antes de avisar del

cambio.

Empleado implementará la interfaz StockListener y realizará alguna acción propia

implementando la función declarada en dicho interfaz (enteradoCambioStock). Esa

acción podría ser la realización de un pedido sobre ese producto.

public class Empleado implements StockListener ()

{

public Empleado (){

}

public void enteradoCambioStock (EventObject ev){

if (ev instanceof StockEvent){



StockEvent event = (StockEvent)ev;

System.Out.println (“Stock Actual:”

+event.getNuevoStock() );

System.Our.println (“Por debajo del mínimo. Se

realizará un pedido.”);

hacerPedido ();

}

}

}

Como la función enteradoCambioStock recibe un objeto de la clase StockEvent,

se puede utilizar las funciones miembro de ese objeto y obtener información sobre el stock

actual (getNuevoStock). La función hacerPedido se debe definir.

Cada listener implementará la función enteradoCambioStock declarada en el interfaz

de la forma que convenga en cada caso.

Resumiendo, cuando un objeto de la clase Producto llama a la función setStock, y teniendo

en cuenta que un objeto de la clase Empleado ha sido añadido a la lista de listeners, ocurriría lo

siguiente:

1. El objeto de la clase Producto llama a la función setStock.

2. En el cuerpo de esta función, se comprueba que el valor de Stock ha cambiado y que

ahora se encuentra por debajo del mínimo.

3. Se notifica el cambio a todos los listeners, llamando a la función notificarCambio.

4. En el cuerpo de la función notificarCambio, se llama a la función

enteradoCambioStock de cada listener.

5. Los listeners implementan el interfaz StockListener.

6. En este caso, el único objeto listener (objeto de la clase Empleado) implementará su

función que imprimirá por pantalla algunos comentarios y realizará un pedido.

En la Fig.1 queda ilustrada la notificación de los eventos desde la fuente a los listeners.

Fig. 1 Fuente y listener

Sierra y Rodríguez


6. PERSISTENCIA:

La persistencia es un aspecto que se encarga de guardar los datos. Es decir, si se crea algo con

alguna aplicación, se guarda y se cierra, al abrirlo se espera que todo siga tal y como se dejó.

Pero dónde se guarda, qué se guarda, cómo se almacena… Lo primero que se debe saber es que

sólo se guardará aquello que tenga que ver con el almacenamiento, todo lo que forma parte del

entorno de ejecución no se almacena (como referencias a otros beans). Cuando un objeto se

almacena exteriormente, deja de formar parte del entorno Java en tiempo de ejecución y no está

sujeto a comprobaciones y restricciones de seguridad impuestas por Java lo que supone un

riesgo.

Se dejará que la aplicación implemente su propio mecanismo de almacenamiento y

recuperación. Así, JavaBeans no tiene un soporte para persistencia, más bien usa un método

primario como la serialización. Pero la persistencia abarca además la seguridad de los beans y la

compatibilidad de versiones.

6.1. SERIALIZACIÓN:

Es la lectura y escritura de objetos a una cadena o stream. El estado de un objeto consiste

en una serie de características o propiedades y valores que serán trasladados a una cadena de

octetos que se almacenará en un archivo. Esta cadena debe contener la información suficiente

para reconstruir el objeto almacenado en su último estado.

Es semejante a si se tomase una foto de un objeto en un momento de la ejecución,

recordándose el valor de sus variables. Se congela la ejecución y se reanudará posteriormente.

Al serializarse se describe completamente su estado y por tanto se serializan todos los objetos

que contenga y los creados automáticamente correspondientes a las superclases de los mismos.

La serialización es el medio para realizar tareas, para almacenar objetos en bases de datos para

uso posterior o transmitirlos a través de la red y que sean usados en el interior de otra

aplicación.



6.2. VERSIONADO:

Cuando se serializa y se guarda un archivo, este queda separado del entorno en tiempo de

ejecución de Java. Como cualquier otro archivo se puede transportar de una máquina a otra y

cargarlo en otro entorno de ejecución Java. Entonces se puede dar la posibilidad de que la clase

responsable de la lectura del objeto no sea idéntica a la clase que la escribió y se produzca una

discrepancia de versiones.

Para que no ocurra esto se intentan acomodar unas versiones con otras y para ello se deben

seguir una serie de directrices a la hora de serializar los objetos: Se leerán o se saltarán siempre

en la misma secuencia en que fueron escritos. Si una versión nueva serializa objetos adicionales

lo hará después de los otros, así la antigua versión sigue funcionando porque lee los objetos que

espera ignorando los añadidos.

Así, hay cambios compatibles con todas las versiones como: adición de campos, adición de

clases, Eliminación de clases, cambio de acceso a un campo…

Pero hay otros cambios que son incompatibles: eliminación de campos, subir o bajar clases

en una jerarquía…

6.3. SEGURIDAD:

La seguridad es un tema muy importante siempre. Vital es conservar la confidencialidad de los

datos e impedir que nadie viole su acceso. Por ello Java tiene un mecanismo bastante complejo,

mecanismo que también incluye JavaBeans.

La serialización es un mecanismo que empeora la seguridad. Al serializar un archivo este está

fuera del entorno de Java y por tanto no sujeto a su protección. Cualquier individuo podría

entrar y ver lo que contiene, pero no es esto lo peor podría hacer cambios para que cuando lo

abramos de nuevo no reconozcamos nada de cómo nosotros lo dejamos.

7. RESUMEN Y CONCLUSIONES:

El progreso de la creación de software se debe en gran parte a la reutilización. Como en todos

los tipos de industria, se tiende a la producción en serie y para ello se necesitan componentes

básicos que uniéndose produzcan el producto deseado.

Los javabeans no son más que una clase de Java que sigue ciertas normas o patrones de

Sierra y Rodríguez


diseño. Todo javabean debe cumplir cinco propiedades fundamentales: introspección,

personalización, eventos, propiedades y persistencia.

Introspección significa que ha de haber alguna manera de analizar ese bean. Esto se logra

mediante patrones (en propiedades, métodos y eventos) y con reglas de los lenguajes.

Personalización no es otra cosa que la capacidad que debe tener un bean para adecuarse a

un proyecto determinado y a las posibles modificaciones que el programador quiera realizar.

Los javabeans rigen sus acciónes mediante eventos. Son los mensajes con los que se

comunican unos y otros. Habrá una fuente de esos eventos y habrá algún bean que espere ciertos

eventos para realizar determinadas acciones.

Muy relacionado con lo anterior se encuentran las propiedades entre las que se debe

diferenciar entre simples, indexadas, ligadas y restringidas. Estas dos últimas generan una

relación entre diferentes beans, puesto que cuando el valor de una de estas propiedades cambia,

generan un evento que puede ser “escuchado” por otros beans para realizar acciones en

respuesta a ese cambio. (fuente listener).

Persistencia es la capacidad que ha de tener un bean para que el programador sea capaz de

guardar su configuración y poderla restaurar más tarde.

8. REFERENCIAS:

[1] Pedro Manuel Cuenca Jiménez “Programación en Java” ANAYA Multimedia (1997)

[2] Piroz Mohseni, Tom Stewart “Guía de desarrollo de JavaBeans” ANAYA Multimedia

(1997)

[3] http:// www.dcc.uchile.cl/~lmateu/CC60H/Trabajos/fpicero

Date post:	21-Oct-2015
Category:	Documents
Upload:	alkakita
View:	38 times
Download:	4 times

Java beans Universidad de Salamanca.pdf

Documents