Está en la página 1de 12

Fundamentos de la Programacin Orientada a Objetos

Diseo de clases

Programacin Orientada a Objetos Facultad de Informtica

Juan Pavn Mestras Dep. Ingeniera del Software e Inteligencia Artificial Universidad Complutense Madrid

Los cambios en el software


El software cambia
Los requisitos cambian Se necesita nueva funcionalidad Mejoras de eficiencia Correccin de errores Adaptacin a plataformas, componentes

Y a lo largo de su vida pasa por muchas manos


Mltiples desarrolladores

El software que no se mantiene cae en desuso


Qu software hay en tu PC que no hayas actualizado alguna vez?

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

Diseo de clases
Caractersticas de un buen programa
Fcil de entender Mantenible Reutilizable

Hay principios de diseo que ayudan en el diseo de las clases y la estructura del programa:
Diseo dirigido por responsabilidades Acoplamiento y cohesin Refactorizacin

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

Ejemplo de trabajo: El mundo de Zuul


Juego de aventuras
Veremos cmo ir mejorando el diseo inicial

Colossal Cave Adventure (Will Crowder, 70)


Juego que trata de encontrar un camino a travs de un complejo sistema de cuevas, ubicar el tesoro escondido, usar palabras secretas y otros misterios, todo ello con el propsito de obtener el mximo nmero de puntos

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

Ejemplo de trabajo: El mundo de Zuul


Ejemplo de cdigo no muy ejemplar
chapter07/zuul-bad

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

El mundo de Zuul
Clase Game
Clase principal que inicia el juego y permite empezar un ciclo de lectura y ejecucin de comandos Tambin tiene el cdigo que implementa cada comando

Clase CommandWords
Define todas las palabras de posibles comandos

Clase Command
Representa un comando introducido por el usuario y permite controlar si es vlido y considerar por separado la primera y segunda palabras

Clase Room
Representa una habitacin que puede tener varias salidas para ir a otras habitaciones

Clase Parser
Se encarga de interpretar la entrada del usuario y trata de crear los objetos Command correspondientes
Juan Pavn Mestras Facultad de Informtica UCM, 2007-08 Programacin Orientada a Objetos

Calidad del diseo de clases


Acoplamiento
Interconectividad de las clases
Si dos clases dependen mutuamente en muchos detalles se dice que estn fuertemente acopladas

Una buena propiedad es el acoplamiento dbil


Que las clases sean lo ms independientes posibles Y que se comuniquen a travs de pequeas interfaces bien definidas

Cohesin
Cunto se ajusta una unidad de cdigo a una tarea lgica o a una entidad
El nmero y diversidad de tareas que se asignan a una unidad

Una buena propiedad es una alto grado de cohesin


Cada unidad de cdigo (mtodo, clase o mdulo) es responsable de una tarea bien definida o de una entidad
Juan Pavn Mestras Facultad de Informtica UCM, 2007-08 Programacin Orientada a Objetos

Calidad del diseo de clases


Un sistema fuertemente acoplado (esto es, con muchas dependencias entre clases)
Ser ms o menos fcil de modificar? Afectarn sus cambios a otras clases? Mejorar su mantenibilidad?

Si un mtodo es responsable de una nica cosa bien definida seguramente podr ser usado nuevamente en un contexto diferente
Ms fcil entender lo que hace Asignar nombres ms descriptivos Mayor reutilizacin

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

Calidad del diseo de clases


Cohesin de mtodos
Cada mtodo debe ser responsable de una y solo una tarea bien definida

Cohesin de clases
Cada clase debe representar una sola entidad bien definida

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

Duplicacin del cdigo


Un indicador de mala calidad de diseo
Hace ms difcil el mantenimiento del cdigo Puede inducir a la introduccin de errores durante el mantenimiento
Inconsistencias Se cambia el cdigo en un sitio pero no en otro similar

Ejemplo: mtodos printWelcome() y goRoom() en la clase Game


Ambos mtodos imprimen informacin pero ninguno puede llamar al otro porque cada uno de ellos, adems, hace otras cosas

La solucin?
Refactorizar cdigo en un mtodo: private void printLocation()

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

10

Hacer extensiones
Supngase que se quiere aadir la posibilidad de ir en otras direcciones, por ejemplo: go up y go down
Qu clases y mtodos habr que tocar?
Room Game Estn fuertemente acopladas

Una solucin al acoplamiento fuerte: el encapsulamiento

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

11

Hacer extensiones
public class Room { public String description; public Room northExit; public Room southExit; public Room eastExit; public Room westExit; // utilizacin: }
// Try to leave current room. Room nextRoom = null; if(direction.equals("north")) { nextRoom = currentRoom.northExit; } if(direction.equals("east")) { nextRoom = currentRoom.eastExit; } if(direction.equals("south")) { nextRoom = currentRoom.southExit; } if(direction.equals("west")) { nextRoom = currentRoom.westExit; Juan Pavn Mestras Programacin Orientada a Objetos Facultad de Informtica UCM, 2007-08 }

12

Hacer extensiones
public class Room // encapsulando { private String description; private Room northExit; private Room southExit; private Room eastExit; private Room westExit; public Room getExit(String direction) { if (direction.equals(north)) return northExit; if (direction.equals(south)) return southExit; if (direction.equals(east)) return eastExit; if (direction.equals(west)) return westExit; } } // utilizacin:
// Try to leave current room. Room nextRoom = currentRoom.getExit(direction);
Juan Pavn Mestras Facultad de Informtica UCM, 2007-08 Programacin Orientada a Objetos

13

Hacer extensiones
Prueba a mejorar la manera de imprimir la informacin de ubicacin (mtodo printLocation())
Esto ser ms fcil con un mtodo que describa las salidas disponibles de una habitacin en la clase Room:
public String getExitString()

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

14

Hacer extensiones
Lo mejor de todo es que ahora se puede utilizar cualquier representacin interna para las salidas de una habitacin ya que ninguna clase accede directamente a esos campos Por ejemplo, usando un HashMap
Ver cdigo en chapter07/zuul-better La clase es ms corta Mtodos ms simplificados Ms fcil de ampliar los tipos y el nmero de salidas

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

15

Diseo dirigido por responsabilidades


Asignar responsabilidades bien definidas a cada clase
En qu clase habr que poner un nuevo mtodo? Cada clase es responsable de gestionar sus propios datos La clase que posee unos datos tiene que ser responsable de procesarlos

Un buen diseo dirigido por responsabilidades conduce a reducir el grado de acoplamiento

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

16

Localizacin de cambios
Uno de los objetivos de un buen diseo de clases es facilitar la localizacin de los cambios
Las modificaciones en una clase deberan tener efectos mnimos sobre las otras clases Por eso hay que evitar definir campos pblicos y definir claramente la interfaz de uso de la clase como un conjunto de mtodos pblicos Los mtodos pblicos de la clase no deberan cambiar
Si acaso aadir otros nuevos

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

17

Acoplamiento implcito
Cuando una clase depende de la informacin interna de otra pero esta dependencia no es inmediatamente obvia
El uso de campos pblicos puede ser obvio
Si se cambian se producirn errores al compilar las clases que los usen

Pero hay casos ms difciles de detectar


Ejemplo: qu pasa si se quieren aadir ms comandos en el juego? Ejercicio: Agrega el comando eat para que cuando se ejecute aparezca el texto I have eaten and I am not more hungry

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

18

Pensar en futuro
Al disear clases hay que pensar cmo podran ampliarse en el futuro
Qu podr cambiar?

La encapsulacin ayuda mucho

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

19

Refactorizacin
Al ir modificando las clases normalmente se va aadiendo ms y ms cdigo
Las clases y los mtodos suelen crecer Habr que refactorizar para mantener buenos niveles de cohesin y bajo acoplamiento

La refactorizacin no se tiene que hacer a la vez que otros cambios


Primero hacer la refactorizacin sin cambiar la funcionalidad Luego probar el cdigo resultante para asegurarse que sigue funcionando correctamente

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

20

Cuestiones de diseo
Qu tamao debe tener una clase? Qu tamao debe tener un mtodo?
La respuesta est en sus responsabilidades, la cohesin y el acoplamiento

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

21

Cuestiones de diseo
Un mtodo es demasiado largo si hace ms de una tarea lgica Una clase es demasiado compleja si representa ms de una entidad lgica

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

22

Como ejercicio
Ms extensiones al juego
Cambiar el idioma de los comandos (por ejemplo, a espaol) Hacer un programa main() que permita ejecutar el juego fuera de BlueJ Definir una configuracin de habitaciones en tres dimensiones para el juego y probarla Aadir llaves en el juego que puedan estar en habitaciones y que sirvan para abrir puertas especiales Aadir puntuacin al juego Invntate una extensin

Juan Pavn Mestras Facultad de Informtica UCM, 2007-08

Programacin Orientada a Objetos

23

También podría gustarte