Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Diseo de clases
Juan Pavn Mestras Dep. Ingeniera del Software e Inteligencia Artificial Universidad Complutense Madrid
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
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
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
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
Cohesin de clases
Cada clase debe representar una sola entidad bien definida
La solucin?
Refactorizar cdigo en un mtodo: private void printLocation()
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
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()
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
15
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
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
18
Pensar en futuro
Al disear clases hay que pensar cmo podran ampliarse en el futuro
Qu podr cambiar?
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
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
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
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
23