Profesor: Juan José González Faúndez Curso: Sistemas de Información II Universidad Andrés Bello Campus República

Profesor: Juan José González Faúndez Curso: Sistemas de Información II

Universidad Andrés Bello Campus República

Un problema de diseño orientado a objetos Imagine un sistema que usa sensores de temperatura para monitorear la condición de un

dispositivo de hardware en algún orden específico.

El primer modelo de estos dispositivos usa sensores de la empresa TempUnab, Inc. Modelo

UB7000.

TempUnab nos provee una clase simple en Java para comunicarnos con el sensor:

Class UB7000 { double getTemp(); … }

Acá se muestra el código de monitoreo que simplemente calcula la temperatura reportada por el

sensor.

double sum = 0.0; for (int i = 0; i < sensors.length; i++) sum += sensors[i].getTemp(); double finalTemp = sum / sensors.length;

Note que sensors está declarado como un arreglo de objetos del tipo UB7000.

¿Algún problema hasta el momento? Parece que no, entonces, echémosle pa’ elante

programming!

El segundo modelo de dispositivo usa más sensores de temperatura y el diseño usado es una

mezcla de sensores UB7000 provenientes de un nuevo proveedor.

Los sensores de la empresa Valuesoft (el nuevo proveedor) son SuperTemps y la clase de interface

de comunicación que nos proveen es:

class SuperTempReader { // // NOTE: temperature is Celsius tenths of a degree // double current_reading(); ... }

Profesor: Juan José González Faúndez Curso: Sistemas de Información II Universidad Andrés Bello Campus República

Profesor: Juan José González Faúndez Curso: Sistemas de Información II

Universidad Andrés Bello Campus República

Esta es una forma terrible de acomodar ambos tipos de sensores:

for (int i = 0; i < sensors.length; i++) { if (sensors[i] instanceof UB7000) sum += ((UB7000)sensors[i]).getTemp(); else // Debería ser un SuperTemp! sum += ((SuperTempReader)sensors[i]).current_reading() * 10; }

En este caso sensors es un arreglo de objetos. El tipo se pone a prueba con una adecuada

conversión usando instanceof y el método de llamada es ejecutado (getTemp y current_reading).

¿Qué hay de malo en este código?

Los problemas surgieron cuando un componente de un segundo proveedor fue introducido al

sistema. Más proveedores pueden estar involucrados en el futuro.

No tenemos ningún control sobre el nombre del método de notificación de la temperatura en las

clases proporcionadas por los proveedores y, además, el valor producido puede necesitar escalar,

también puede requerir conversión de unidades, etc.

Dentro del conjunto de patrones de diseño vistos en clases, analice la

posibilidad de que alguno de ellos nos provea una solución a este problema.

Haga el diseño de clases inicial (para que visualice el problema), luego

aplique el patrón de diseño en un diagrama de clases diferente y pruebe la

solución en código Java o el lenguaje OO que más le acomode. MENOS

VISUAL BASIC!

Tiempo estimado de solución: 1 hora 30 minutos.