Aspectos Básicos de Diseño

Presentación del tema: "Aspectos Básicos de Diseño"— Transcripción de la presentación:

1 Aspectos Básicos de Diseño
Universidad de Chile Departamento de Ciencias de la Computación Prof.: Nancy Hitschfeld Kahler

2 Contenido Diseño de una buena clase Relaciones entre clases
Notación UML Uso correcto de herencia Patrones de diseño Evaluación de diseños: Métricas Metodologías de diseño y programación

3 ¿Cómo diseñar una buena clase? [Mey97]
Clase conocida por su interfaz (métodos)‏ Principio de lista de compras Descripción simple y coherente (no más de una página)‏ Nombre apropiados Uso de contratos: precondiciones, post condiciones e invariantes (depuración y documentación) [Mey97] Mecanismo de excepción para situaciones anormales Una buena clase se caracteriza por lo siguiente: - está definida por su interfaz, - sus métodos no requieren un cierto orden de uso, es decir, que algunos deban ser llamados siempre antes que otros. Este principio de conoce como la lista de compras, pues cuando una persona va al supermercado, puede comenzar comprando cualquiera de los productos anotados. - la descripción de la clase y de cada uno de los métodos debe caber en una página, de lo contrario el código no es muy legible, - debe definir contratos para ayudar a la depuración del programa y la descripción de la clase. Si un contrato reclama en la precondición, el culpable es el objeto que llama a ese método o el usuario. Si un contrato se cae en una postcondición, el programador del método debe revisar el código escrito. Si el invariante tiene problemas, también le corresponde al desarrollador del sistema revisarlo. Por ello hasta es una herramienta muy útil para la depuración, pues el programa deja de funcionar donde se produce el error (el error no se propaga en el código). Metodologías de diseño y programación

4 Pasos a seguir: (enfoque minimal)‏
Encontrar objetos Diseñar su métodos públicos (interfaz) Definir su implementación Proceso iterativo e incremental Metodologías de diseño y programación

5 ¿Qué puede ser un objeto
¿Qué puede ser un objeto? [Daniel Halbert y Patrick O'Brien: “Using Types and ...” ] Cosas reales o abstractas artículos, cuentas y personas pila, cola y grafo Procesos ordenar, iterador, formateador Metodologías de diseño y programación

6 Cómo diseñar la interfaz?
Donde poner una funcionalidad? Ejemplo: inscribir un estudiante en un curso En la clase Curso? En la clase Estudiante? Crear una nueva clase Inscripción? No hay una regla clara: depende de los requerimientos de la aplicación Examinar: Reusabilidad Complejidad Aplicabilidad Conocimiento de la implementación Metodologías de diseño y programación

7 Reusabilidad Es útil este comportamiento en más de un contexto?
Crear clase si el comportamiento puede ser reusado en varios contextos u otras clases Ejemplo: Recorrer una lista : el mismo recorrido puede ser aplicado a varias listas. (Patrón de diseño iterator)‏ Concepto de rectángulo: reusado en ventana y figuras gráficas Metodologías de diseño y programación

8 Aplicabilidad Qué tan relevante es un comportamiento?
Desea la mayor parte de los clientes usar este comportamiento? Ejemplos: Convertir a mayúsculas como método en clase String (es solo relevante aquí) Parsing de una línea en clase aparte (no es método clásico asociado a String). En Java? Metodologías de diseño y programación

9 Complejidad Qué tan difícil es implementar este comportamiento?
Crear una clase si el comportamiento es complejo Ejemplo: Calcular el área es simple; incluir en Rectángulo Parsing de una línea es complejo; modelar este porceso como una clase Intersección de figuras: va en mas de una clase el mismo método y es complejo; Modelar como una clase Metodologías de diseño y programación

10 Conocimiento de la implementación
En qué grado su implementación depende del tipo al que es asignado Muy dependiente => incluirlo en clase asociada Que decidir en caso que dos criterios den resultados distintos? Usar criterio de mayor peso (depende de los requerimientos de la aplicación) Metodologías de diseño y programación

11 Relaciones entre clases
Especialización/generalización Herencia IS-A? Parte/Todo IS-PART-OF, HAS-A? Agregación y composición Asociación Colaboración Independencia De uso Relación más débil Las relaciones entre clases más comunes son: - Especialización (o generalización). Esta relación se conoce como "Is a", dado que los objetos de la subclase son también objetos de la superclase. -Parte/Todo: el objeto descrito por la clase esta compuesto de objetos definidos por otras clases. -Asociación: Denota una dependencia semántica entre las clases. Las objetos existen independientemente y colaboran para lograr un objetivo común. -De Uso: Es cuando un objeto es cliente de otro. Por ejemplo lo usa para calcular ciertos valores. Metodologías de diseño y programación

12 Relaciones entre clases (2)‏
Ejemplo: Una rosa es una flor Existen rosas de diferentes colores Una flor se compone de pétalos, aroma, etc. Las abejas usan el néctar de las flores para alimentarse Las abejas ayudan a polinizar las flores El clavel es otra flor Metodologías de diseño y programación

13 Relaciones entre clases (3)‏
El diagrama representa las siguiente relaciones: - Una rosa "es una" flor, por lo tanto rosa es más especializada que flor. - Pétalo no es un tipo de flor, pero si es parte de una flor - Abejas y flores cooperan entre si Metodologías de diseño y programación

14 Relaciones entre clases (4)‏
Diferencia entre composición y agregación Composición: tiempo de vida de la variable de instancia está ligada a la del objeto que la contiene Agregación: tiempo de vida de la variable de instancia es independiente del objeto que la contiene. Metodologías de diseño y programación

15 Relaciones entre clases (5)‏
- Relación de uso: - Implementación de una interfaz - Asociación dirigida Metodologías de diseño y programación

16 ¿Cuándo usar herencia? [Alb87]
Subtipos ( forma natural: subconjuntos) ¿Por qué? El objeto heredado válido en el contexto de clase padre El objeto heredado redefine métodos y/o agrega nuevos Problemas en caso contrario: Malos diseños Falsas expectativas Metodologías de diseño y programación

17 ¿Cuándo usar herencia?(2)‏
Especialización subclases subconjuntos de clase padre Implementación misma interfaz, distinta implementación Combinación subclase subconjunto de dos o más clases Metodologías de diseño y programación

18 ¿Cuándo usar herencia?(3)‏
Metodologías de diseño y programación

19 ¿Cuándo NO usar herencia?
Generalización: subclase generalización de clase padre Varianza: subclase hermano de clase padre Errores comunes: Heredar de partes Heredar privadamente (C++). Alternativa: agregación o composición Metodologías de diseño y programación