Una vez más tomamos como base la
solución al enunciado de la práctica anterior (la segunda, en este caso).
Completaremos un poco más la noción de cuenta
y de cajero al permitir por parte de
este último la eliminación de una cuenta a petición propia. Obviamente, esto
tendrá ligeras repercusiones sobre los métodos que ofrece la cuenta y los métodos implementados en
los callbacks de la práctica anterior.
Entre las tareas que deberá resolver
el cajero está el de liquidar previamente el saldo de la cuenta (o en su caso
cubrir el descubierto) antes de eliminar. Una vez resuelta esta cuestión,
cuando el saldo de la cuenta es “0”
podemos disparar un método de la cuenta que sirva para “eliminar” la cuenta. Como veremos este punto tiene sus
implicaciones, en primer lugar debemos incluir una notificación adicional en
los callbacks para poder decirles que la cuenta no
existe más. En segundo lugar, y puesto que puede haber todavía referencias
remotas y locales a una cuenta “eliminada”
debemos blindar el comportamiento del objeto frente a nuevas invocaciones de
sus métodos, lo que nos lleva a la construcción de una excepción específica
nueva para notificar esta situación.
La interfaz cuenta
además de la interfaz establecida en las prácticas anteriores deberá
disponer de un método adicional: “eliminar”,
que disparará métodos para avisar a los callbacks de
la finalización de la existencia del objeto cuenta concreto.
El mensaje “eliminar”
solo funcionará en caso de que el saldo de la cuenta sea “0”.
La interfaz de los objetos callback debe contener un método
adicional “cuentaEliminada”
donde cada objeto de tipo cuenta notificará que dicha cuenta ha dejado de
existir.
La invocación futura de mensajes sobre el objeto
cuenta finiquitado producirá una excepción que notificará la finalización del
objeto y no se realizarán las acciones derivadas del desencadenamiento del método
en cuestión.
El objeto
cuenta finiquitado deberá eliminarse del registro de nombres de objetos remotos.
Los cajeros y cualquier clase que contenga
referencias a una cuenta eliminada deberán deshacerse de la referencia al
objeto cuanto antes, para que el recolector de basura pueda eliminar el objeto
en el menor tiempo posible.
En consonancia con lo anterior, al “eliminar” una cuenta deberá eliminarse
su nombre del registro RMI (cuidado con
este requisito que es un poco peliagudo).
Este es el momento para recapitular y rehacer la
práctica que pudieras haber hecho en algún momento, pues la adición de
modificaciones de la segunda práctica y ésta, la tercera, hacen inviable que un
código deficiente funcione.
Relee los enunciados de las prácticas una y otra
vez hasta que los comprendas perfectamente.
Haz uso del foro y anima a cualquier compañero a
hacer uso de él para resolver dudas, puesto que resulta en un beneficio mutuo.
OJITO, no
dejéis soluciones a partes o a la totalidad de la práctica en el foro.
Cada grupo deberá depositar los archivos de la
práctica (sin comprimir) sobre un directorio denominado "SD2PC" que estará situado en su
directorio de inicio en el host "duero.lab.fi.uva.es".
Basta con que uno de los miembros del grupo deposite la práctica de esta forma.
En este directorio deberá haber un archivo
denominado "componentes"
con los nombres completos de los integrantes del grupo de prácticas. Sin
perjuicio de que pueda aparecer su nombre en el resto de la documentación.
La práctica será recogida de forma automatizada
por los técnicos del centro mediante un script que entrará en funcionamiento a las 0 horas del día 9 de Septiembre de 2004.
Es decir, teneis de plazo para depositar la práctica
hasta las once horas y 59 minutos de la noche del miércoles día 8 de Septiembre.