Diseo con reutilizacin

Tabla de contenidos 1. Introduccin.............................................................................................................246 2. Diseo de un hotel...................................................................................................246

2.1 La semejanza entre dos problemas software..........................................................246 2.2 El misterio del recurso que no aparece...................................................................250 2.3 El peso del atributo disponibilidad.........................................................................250 2.4 Eficiencia Desarrollo vs. Eficiencia Ejecucin.......................................................252 2.5 Una dinmica comn...............................................................................................252 2.6 Un patrn comn......................................................................................................254 Ejercicio..........................................................................................................................256

3. Una ampliacin del hotel........................................................................................257

3.1 El largo camino de una solucin..............................................................................257

4. Eplogo......................................................................................................................262

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

1. Introduccin
El propsito de este captulo es disear un sistema software que se parece a un diseo previo. Habr que reconocer en qu se parecen los dos problemas y reutilizar aquella parte del diseo anterior que sea til para el diseo nuevo.

2. Diseo de un hotel
El cliente del cajero nos recomend a un amigo suyo para otro trabajo. Ahora nos piden hacer software para la reserva y alquiler de habitaciones en un hotel. Con la experiencia que ya tenemos debemos plantearnos si empezamos desde cero o reutilizamos algo. Tratemos de reutilizar, aunque a primera vista, el problema del cajero no se parece al del hotel.

2.1 La semejanza entre dos problemas software Los datos que se manejan en el caso del cajero no tienen nada que ver con los datos que se manejan en el caso del hotel. Figura 1. Parecen ser dominios diferentes sin ningn concepto en comn que pueda ser reutilizado. Pero slo hemos mirado hacia los datos. HOTEL
CAJERO

cuenta extraccin monedero tarjeta ingreso

alquiler habitacin reserva

Figura 1. Datos del Cajero y el Hotel

246

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Cambiemos el punto de vista y pensemos en los mecanismos. El software del cajero permite que un cliente pueda hacer retiros o ingresos de dinero en su cuenta bancaria. Para poder realizar el retiro, se requiere que el cliente tenga dinero disponible en su cuenta bancaria y, tambin, que el monedero tenga dinero disponible para entregar la cantidad pedida. El ingreso siempre se puede realizar, no impone restricciones. Despus de realizar cualquiera de las operaciones el software actualiza la cuenta del cliente y, en el caso del retiro, se actualiza tambin el monedero.

Selector

Operacin

Cuenta

Extraccin
Ingreso

Monedero

Figura 2. Diagrama de clases simplificado del cajero El software del hotel, por su parte, debe permitir reservar o alquilar las habitaciones de un hotel. Para poder reservar una habitacin se necesita que la habitacin este disponible. Para alquilarlo se requiere que la habitacin tambin est disponible, ya sea porque est libre o porque ha sido reservada a nombre de la persona que quiere hacer el alquiler. Figura 3. Para apreciar mejor la esencia del mecanismo, hemos omitido el dibujo de los gestores de colecciones y las interfaces, en el cajero y en el hotel, pero estn presentes. Selector
Operacin

Habitacin

Disponibilidad

Reserva

247

Alquiler

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Figura 3. Diagrama de clases simplificado del hotel En ambos casos se trata de realizar operaciones sobre algo. Las operaciones en el caso del cajero son el retiro y el ingreso, y las operaciones en el caso del hotel son la reserva y el alquiler. El software debe permitir la seleccin de la operacin que desea realizar y despus ejecutar esta operacin. La Figura 4 muestra una estructura comn que satisface las dos situaciones.

Selector

Operacin

Algo

Operacin 1

Operacin 2

{Otra Operacin}

Figura 4. Generalizacin excesiva del cajero y el hotel Efectivamente existe algn parecido, pero es demasiado general, muchos sistemas software tienen esta estructura. Intentemos precisar ms, estudiando con detenimiento ese Algo sobre el que se ejecutan las operaciones. En el caso del hotel ese Algo es Habitacin, que se alquila y se reserva. En el caso del cajero ese Algo es Cuenta sobre la que se extrae y se ingresa dinero. Pero,
248

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Habitacin y Cuenta continan sin tener un elemento comn. Volvamos al hotel. La habitacin es un recurso del hotel; un recurso del que se necesita conocer su disponibilidad. Figura 5.

Selector

Operacin

Recurso

Disponibilidad

Operacin 1

Operacin 2

{Otra Operacin}

Figura 5. Generalizacin del hotel La situacin del cajero es semejante. Se acta sobre un recurso del que se necesita conocer su disponibilidad: el dinero. La diferencia es que el recurso no aparece de forma explcita. Las operaciones se ejecutan directamente sobre su disponibilidad. La disponibilidad del dinero en el banco, a travs de la cuenta y en efectivo, a travs del monedero. Por esta causa no terminbamos de encontrar el encaje entre el cajero y el hotel, a pesar de su gran semejanza. Al omitir el recurso, en el cajero, fallaba nuestro intento de hallar un parecido entre habitacin y cuenta, porque estbamos comparando conceptos diferentes: recurso y disponibilidad. Sin embargo, los dos problemas tienen una esencia comn. Son operaciones sobre recursos que tienen una disponibilidad limitada. Por tanto, deben compartir una estructura y una dinmica comn. Parte de la estructura ya la descubrimos en la Figura 5 al generalizar el hotel. De la dinmica, nos ocuparemos despus.

249

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

2.2 El misterio del recurso que no aparece Continuemos, ahora, estudiando porqu se omite el recurso en el cajero y porqu aparece en el hotel. En el cajero, el dinero es un recurso cuantitativo, mil pesetas no se diferencian de mil pesetas. Pero, en el hotel, una habitacin es distinta de otra, aunque slo sea por su nmero de identificacin. En el cajero no se distinguen los recursos por su cualidad, mientras que en el hotel si se distinguen. Esto justifica la omisin del recurso en el cajero y su aparicin explcita, individualizada, en el hotel. Un tratamiento cuantitativo de las habitaciones dificultara cargar los gastos de los clientes a las habitaciones que alquilan, como se hace habitualmente. Dificultara apreciar las incidencias sobre una habitacin en particular y dificultara hasta que un cliente pudiese alquilar una habitacin especfica para recordar una historia pasada. En fin. Aclarada la diferencia entre el cajero y el hotel respecto a la omisin y aparicin del recurso, en la estructura del software, estudiemos el aspecto disponibilidad.

2.3 El peso del atributo disponibilidad La disponibilidad de las habitaciones fue la pista para encontrar que la cuenta y el monedero eran expresiones de disponibilidad en el cajero. Gracias a su planteamiento explcito en la Figura 3, repetida ahora por comodidad, nos dimos cuenta que, en el cajero, se actuaba directamente sobre la disponibilidad, omitiendo el recurso. Por tanto, fue muy importante hacerla explcita en nuestro esquema inicial. Figura 6.

250

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Selector

Operacin

Habitacin

Disponibilidad

Reserva

Alquiler

Figura 6. Repeticin de la estructura del hotel Sin embargo, quizs no merece la pena hacerla explcita en el caso concreto que nos ocupa, porque la disponibilidad puede tomarse como un atributo de la habitacin. Cierto, pero sera un atributo complejo, lo que sugiere su separacin de la habitacin. La disponibilidad de una habitacin tiene, a primera vista, tres estados: libre, alquilada o reservada, a lo largo de un perodo determinado, digamos seis meses. En consecuencia, tendremos que manejar unos ciento ochenta estados por habitacin. Con la particularidad, adicional, de que esa lista de estados debe ser desplazada cada da para mantener constante su longitud de seis meses. Es una gestin demasiado compleja para incluirla en las tareas de la habitacin, aunque conceptualmente la disponibilidad sea un atributo de habitacin. En trminos de objetos, cada objeto oHabitacin debe delegar en otro objeto oDisponibilidad, de su propiedad, esta gestin. Visto al revs, cada objeto oDisponibilidad sera un agregado de un objeto oHabitacin en el que se delega la realizacin de las tareas de la disponibilidad del objeto oHabitacin. Este es un caso claro de agregacin fuerte. La disponibilidad de una habitacin slo tiene sentido mientras exista la habitacin.

251

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

El hotel nos recuerda a la biblioteca, que ya estudiamos en un captulo precedente. Por tanto, podemos pensar en reutilizar esa idea. Pero las diferencias cuantitativas y cualitativas entre ambos pueden sugerir en buscar otro camino.

2.4 Eficiencia Desarrollo vs. Eficiencia Ejecucin Siguiendo la lnea del dilogo directo entre los objetos interesados, como se hizo en el cajero, la disponibilidad en el hotel se averigua y se modifica a travs de cada habitacin. La influencia estructurada puede sugerir que el gestor de habitaciones, puesto que son varias, se ocupe de averiguar de la disponibilidad en el hotel. Esto requiere una especializacin del gestor, que se justifica cuando hay problemas con la eficiencia de la mquina. Pero la especializacin del gestor introduce heterogeneidad en el software que aumentan su complejidad, al diferenciarse un gestor de otro. Y adems, la especializacin del gestor, dificulta la evolucin posterior del software. La funcin de los gestores es facilitar la manipulacin de la coleccin de objetos y esconder la manera de acceder a ellos, no ms. Al separar el acceso y la manipulacin de la coleccin, de la accin sobre cada miembro de la coleccin, se facilitan las modificaciones posteriores de los gestores y, tambin, las modificaciones sobre los miembros de la coleccin por separado. Por tanto, se facilita la evolucin. El objetivo de conseguir un software eficiente desde el punto de vista de la mquina y el objetivo de conseguir un software eficiente desde el punto de vista de su evolucin, son objetivos generalmente contradictorios. Nuestro mtodo se decanta por la eficiencia de la evolucin.

2.5 Una dinmica comn Adems de una estructura comn entre el hotel y el cajero, tambin es comn la dinmica. Las operaciones del cajero hacen extracciones e ingresos sobre un recurso. Las del hotel, casi igual. Las operaciones de alquiler y reserva extraen un recurso, una habitacin. Por tanto, su funcionamiento debe ser muy semejante al funcionamiento de Extraccin. De manera que podemos copiarlo, haciendo los ajustes pertinentes. Una
252

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

vez ms, ganamos porque no tenemos que partir de cero para construir una aplicacin nueva. Pero aqu no acaban las ganancias. La comparacin de las operaciones del hotel y el cajero muestra la falta del equivalente a la operacin de ingreso, en el hotel. Nadie le ha mencionado hasta ahora, sin embargo, tiene sentido que exista porque de lo contrario se agotar el recurso. Entonces, podemos prever que nos pedirn una operacin de reposicin de las habitaciones, aunque no lo hayan dicho. Esto es otra ventaja de encontrar la similitud entre dos problemas software. Similitud que debe ser tratada con sus diferencias respectivas por separado y no en un solo elemento. Por ejemplo, la similitud entre alquiler y reserva debe aprovecharse para copiar el diseo de una a otra, pero deben disearse como clases separadas, hijas de una madre comn. Aunque las operaciones de alquiler y reserva nos parezcan iguales, no son sinnimas conceptualmente. Hay alguna diferencia entre ellas. Por ejemplo, por una se paga y por la otra no. Si las reunimos en una sola clase Operacin, por esa mana de ahorrar cdigo, tendemos que distinguirlas a travs de un parmetro que tomar valor en tiempo de ejecucin. Una vez ms, habremos aumentado la complejidad del cdigo al esconder su diversidad. Y, una vez ms, tambin habremos complicado la modificacin del software porque al cambiar una de las operaciones habr que tocar la otra. La reunin de alquiler y reserva en una sola clase, porque ahora la diferencia es pequea, congela el futuro a nuestra visin del presente. Si la evolucin conduce a un aumento de la diversidad debemos esperar que la diferencia aumente. Por tanto, es prudente plasmar la diferencia desde ahora, por pequea que sea. Siguiendo ese estilo de diseo, si nos piden tener en cuenta el alquiler de una habitacin que ha sido reservada, debemos aadir una nueva clase Alquiler con reserva como hermana de Alquiler y de Reserva. Ella se encargar de realizar esta operacin especfica, copiando del diseo de sus hermanas aquello que le sea til.

253

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

2.6 Un patrn comn Al precisar que las operaciones del cajero y del hotel tambin son comunes podemos delinear mejor la esencia de ambos problemas: la extraccin y el ingreso sobre un recurso con disponibilidad limitada. De nuevo, hemos llegado a otro patrn, til para diversas aplicaciones. Por ejemplo, el alquiler de coches, de vdeos, la gestin de entradas para el teatro, la gestin de viajes, etc. La Figura 7 muestra la parte estructural del patrn.

Selector

Operacin

Recurso

Disponibilidad

Extraccin

Ingreso

{Otra operacin}

Figura 7. Estructura del patrn para la extraccin y el ingreso sobre un recurso con disponibilidad limitada Disponer de un patrn que exprese la esencia comn de varios mecanismos software, aparentemente diferentes, ofrece unas cuantas ventajas. Primero, no tendremos que empezar de cero si debemos construir alguno de ellos. Segundo, el patrn es un elemento de contraste para comprobar nuestro diseo particular. Por ejemplo, como hicimos con el cajero cuando analizamos la omisin del recurso, y con el hotel, cuando vimos que faltaba una operacin para reponer las habitaciones. Tercero, los patrones reducen la complejidad del diseo, porque permiten operar con piezas ms grandes, ocultando detalles. Cuarto, los patrones facilitan la comunicacin entre diseadores por la misma condicin de trabajar con piezas mayores, comunes a diversos sistemas software.

254

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Pero, para lograr esas ventajas es necesario pensar en trminos de patrones, obtener patrones o conseguirlos en la literatura y estudiarlos profundamente antes de aplicarlos. Hay muy pocas cosas gratis en este mundo. El anlisis de la similitud entre el cajero y el hotel, a partir de los datos, podra haber llegado al patrn, siguiendo un camino de abstraccin semejante al que seguimos con el anlisis del mecanismo. Pero, quizs, no. La generalizacin de Isidoro-Pepe, atendiendo slo a los datos, a los participantes, produjo una abstraccin intil para el caso Despertador-Persona porque no se tuvo en cuenta la funcin. El software es una mquina. Y, adems, hubiera sido ms difcil porque estamos acostumbrados a pensar en trminos de funciones. Por todo esto, es aconsejable buscar la similitud en los mecanismos.

255

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Ejercicio Desarrollar el software para la reserva y alquiler de habitaciones en un hotel a partir del patrn obtenido.

256

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

3. Una ampliacin del hotel Supongamos que se nos pide ampliar el sistema para alquilar y reservar salones que se usan en las cenas, comidas y fiestas. El alquiler y la reserva de los salones ser por horas, a diferencia de las habitaciones que se alquilan y reservan por das. Dejemos un espacio para su diseo de esta nueva situacin.

3.1 El largo camino de una solucin La primera solucin, que salta a la vista, es la extensin del patrn de la Figura 7, especializando la clase Recurso como se muestra en la figura 8.

Selector

Operacin

Recurso

Alquiler

Reserva

Habitacin

Saln

Figura 8. Extensin del patrn para varios recursos Tal extensin supone que las operaciones de alquiler y reserva son las mismas para habitacin y saln. Pero no lo son. El problema ha aumentado su diversidad. El manejo de los recursos debe ser distinto. Por tanto, extendemos alquiler y reserva, como se muestra en la Figura 9 para resolver la diversidad. Un alquiler de saln y otro de habitacin, una reserva de saln y otra de habitacin.

257

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Selector

Operacin

Recurso

Alquiler

Reserva

Habitacin

Saln

AlquilerSaln

Alquiler Habitacin

ReservaSaln

Reserva Habitacin

Figura 9. Extensin de las operaciones alquiler y reserva

Pero tambin se nos puede ocurrir la solucin de la Figura 10.

Selector

Operacin

Recurso

AlquilerSaln

Alquiler Habitacin

ReservaSaln

Reserva Habitacin

Habitacin

Saln

Figura 10. Otra solucin para alquiler y reserva de salones

258

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Sin embargo, hemos cado en una trampa, de simplicidad. Ninguna de las dos soluciones es adecuada para el problema de operaciones diferentes sobre recursos diferentes. La conexin entre Operacin y Recurso permite la comunicacin potencial de cualquier operacin con cualquier recurso. Por tanto, si se produce una equivocacin, puede suceder que una operacin acceda a un recurso que no deba acceder. Y basta que exista la posibilidad de error para que suceda. Es como programar c b/a, sin comprobar antes que el denominador es diferente de cero. Una chapuza, en fin. La diferencia de operaciones sobre diferentes recursos, no admite la homogeneidad que impone la conexin entre Operacin y Recurso, en las figuras 9 y 10. Esa conexin viola el requisito de heterogeneidad de las operaciones. Por tanto, debemos eliminarla y unir las operaciones, directamente, con sus recursos correspondientes. Figura 11.

Selector

Operacin

Recurso

Alquiler

Reserva

Habitacin

Saln

AlquilerSaln

Alquiler Habitacin

ReservaSaln

Reserva Habitacin

Figura 11. Conexin directa de las operaciones con los recursos La solucin es valida, es decir, funciona. Pero la conexin directa, una a una, entre las operaciones y los recursos eleva demasiado la complejidad del diseo. Se
259

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

aument la cantidad de lneas de conexin y adems, potencialmente, se aumentaron las dimensiones del diseo, porque el cruce de lneas indica un posible grafo no plano. Es decir, una solucin con ms de dos dimensiones. La redistribucin de los elementos del diseo demuestra que se puede evitar el cruce de las lneas y que, por tanto, el grafo es plano. Pero esa redistribucin complica la geometra del diseo. En consecuencia, tampoco es una solucin adecuada. El origen del cruce de lneas est en la clasificacin de las operaciones por operaciones. Las de alquiler con alquiler y las de reserva con reserva, siguiendo una taxonoma natural. Suprimamos, entonces, esa clasificacin, a pesar de su naturalidad. Cortemos el nudo Gordiano, colocando todas las operaciones a un mismo nivel y de forma tal, que no se crucen las lneas. Figura 12.

Selector

Operacin

Recurso

AlquilerSaln

Reserva Saln

Alquiler Hab.

Reserva Habitacin

Habitacin

Saln

Figura 12. Diseo que elimina el cruce de lneas El nuevo diseo, que es una variante de la Figura 10, resuelve el problema del cruce de lneas, pero mantiene el problema de la cantidad de lneas. Sin embargo, una mirada a la disposicin de las operaciones, en esta segunda solucin, muestra que las operaciones estn agrupadas por recursos. Intentemos clasificarlas as. Figura 13.

260

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

Figura 13. Clasificacin de las operaciones por recursos

Recurso

Selector

Operacin

Habitacin

Operacin Habitacin

Operacin Saln

Saln

Reserva Habitacin

Alquiler Habitacin

ReservaSaln

AlquilerSaln

Con esta nueva clasificacin desaparecen las conexiones directas, y se vuelve a establecer homogeneidad en el diseo, slo que a un nivel ms bajo, el de los recursos. La solucin de la Figura 13 recupera la estructura del patrn original, que habamos descubierto al contrastar el cajero y el hotel, pero ahora repetido, en virtud de la duplicacin de los recursos. La clasificacin de las operaciones por recursos es ms adecuada teniendo en cuenta que actan de forma diferente. La otra, que saltaba a la vista, no era til en este caso. Lo que pareca natural, por cotidiano, ocultaba la verdadera naturalidad de la solucin. Pero no nos quedemos aqu, comparemos las soluciones. La sensacin visual de complejidad que ofrecen las distintas soluciones se puede ordenar de la siguiente forma Figura 11 > Figura 13 > Figura 12. Si tomamos la cantidad de elementos y de lneas de conexin como medida rudimentaria de complejidad, comprobaremos que el efecto
261

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

visual se corresponde con esa medida. Por tanto parece que perdemos con la solucin de la Figura 13, respecto a la solucin de la Figura 12. Pero no es as. La solucin de la Figura 13 aporta una simetra especular que reduce la complejidad, casi a la mitad, porque se puede tratar por separado cada lado del eje de simetra. En consecuencia, hemos obtenido realmente una solucin mejor, desde el punto de vista de la complejidad. Una solucin que resuelve el problema de la heterogeneidad de los recursos sin aumentar demasiado la complejidad del diseo. Pero que no es idealmente perfecta. La solucin de la Figura 13 consigue aislar cada recurso en una pequea parcela junto con sus servidores, consigue introducir homogeneidad dentro de las parcelas y, adems, obtener parcelas muy semejantes. Pero esta polarizacin del diseo hacia recursos dificulta las modificaciones globales de los alquileres y de las reservas porque renunciamos a la clasificacin taxonmica de las operaciones, para enfrentarnos con la heterogeneidad de los recursos. Dado el estado actual de los lenguajes de programacin orientada a objetos es difcil armonizar el diseo para satisfacer por igual la clasificacin de las operaciones por recursos y por tipo de operacin, porque slo se admite una clasificacin esttica de los elementos de diseo. Fowler, no obstante, describe tcnicas para conseguir el efecto de clasificacin dinmica con los lenguajes actuales, que se pueden usar en caso necesario. La herencia mltiple, que puede venir a la mente para la doble clasificacin, es una alternativa peligrosa, dada su condicin de clasificador esttico que exige a la vez ser una cosa y otra. Aunque se pueden reducir sus efectos peligrosos si se hereda cdigo de un antecesor e interfaz de otro. Pero as todo, hay que tener un cuidado.

4. Eplogo
Cuando comenzamos a resolver el problema del cajero no tenamos una experiencia anterior que nos ayudase a realizar el diseo. Tuvimos que partir de cero y
262

Curso de OO dirigido por la introduccin de ambigedad

Diseo con reutilizacin

construir el diseo poco a poco, valindonos solamente de principios generales. Sin embargo, cuando nos enfrentamos al hotel ya tenamos una experiencia previa que se pudo utilizar como punto de partida. El hotel result ser una variante de un patrn general que engloba al cajero, al hotel y a otros problemas similares. Este salto cualitativo entre el comienzo del cajero y el comienzo del hotel facilita considerablemente la tarea de diseo porque no fue necesario inventarlo todo, como nos inducen a hacer algunos textos de desarrollo de software. Es cierto que se trabaj duro para encontrar el patrn, pero dio resultados. Por una parte, profundizamos nuestro conocimiento de las soluciones software y por otra, nos qued un patrn para ser reutilizado en problemas semejantes. Los procedimientos generales son adecuados si no contamos con otros recursos para resolver un problema del que no conocemos sus particularidades. Pero, si se conocen las particularidades, es ms eficiente aplicar procedimientos e ideas especficas de ese problema concreto. Por tanto conviene desarrollar un estilo de pensamiento que enriquezca nuestro caudal de recursos especficos de diseo, sin perder los generales. Esto supone una actitud reflexiva antes, durante y despus de cada diseo, aconsejable fundamentalmente a los profesionales de software, porque son los que podrn capitalizar mejor, a lo largo de su carrera, el esfuerzo inicial que supone adoptar esa actitud. La reflexin, adems de aumentar la eficiencia de nuestro trabajo, aumenta la capacidad de diseo. Ayuda a detectar efectos indeseables en las decisiones de diseo, como los que descubrimos al tratar de ampliar las operaciones de alquiler y reserva de habitaciones a alquiler y reserva de salones. Ayuda tambin a simplificar, un diseo no debe ser ms complejo que lo exigido por la complejidad del problema porque eleva el coste del mantenimiento y evolucin. En fin que, cualquier decisin de diseo debe ser motivo de reflexin.

263