Diseño Orientado a Objetos Principios y Patrones UTN Facultad Córdoba Laboratorio de Sistemas Ing. Fernando A. Cuenca.

Presentación del tema: "Diseño Orientado a Objetos Principios y Patrones UTN Facultad Córdoba Laboratorio de Sistemas Ing. Fernando A. Cuenca."— Transcripción de la presentación:

1 Diseño Orientado a Objetos Principios y Patrones UTN Facultad Córdoba Laboratorio de Sistemas Ing. Fernando A. Cuenca

2 ¿Qué es “mal diseño”? Rigidez: dificultad para introducir cambios. Fragilidad: efecto cascada. Inmovilidad: reusabilidad dificultosa.

3 Agenda Conceptos de Orientación a Objetos Principios de Diseño O-O Reuso de experiencia: Patrones de Diseño

4 Orientación a Objetos Revisión de conceptos

5 ¿Qué significa “Orientado a Objetos”? Un modelo es orientado a objetos cuando está compuesto por un conjunto de objetos que cooperan entre si enviándose mensajes. Dichos objetos pertenecen a clases, las cuales pueden relacionarse entre si por medio de la herencia.

6 ¿Qué es un Objeto? Un Objeto representa un ítem o entidad individual (ya sea conceptual o real) con un rol bien definido en el dominio del problema.

7 Objetos: algunos ejemplos

8 Caracterización de un Objeto Estado Comportamiento Identidad

9 Clases: dos visiones Plantilla (o template)  Una Clase es la especificación o descripción genérica de un conjunto de objetos Conjunto de instancias  Una Clase es un conjunto de objetos que comparten características y comportamientos comunes

10 Clases vs. Objetos Objeto  entidad individual Clase  Especificación abstracta Todo Objeto es instancia de una Clase

11 Los Objetos colaboran entre si Visión antropomórfica  objetos como “entes vivos” Responsabilidades y Colaboraciones  Relaciones de uso Relaciones estructurales  Agregación o Composición de Objetos

12 Mensajes La única forma de acceder a un objeto es enviándole un Mensaje. “Acceder”  obtener información del objeto  solicitar la realización de una acción El objeto está encapsulado

13 Encapsulamiento Encapsular significa esconder todos los detalles de implementación de un objeto, revelando solamente aquello que es necesario conocer para hacer uso del mismo.

14 Enviando mensajes Emisor y Receptor (cliente y servidor) Selector y Parámetros Método

15 Agrupando métodos Contratos Protocolo

16 Contratos “Un contrato (o interfaz) define un conjunto cohesivo de requerimientos que un cliente puede hacer a un server.”

17 Contratos (cont.) Un contrato es un conjunto cohesivo de métodos Una clase puede implementar muchos contratos El mismo contrato puede ser implementado por diferentes clases Los contratos pueden especificarse independientemente de las clases que los implementan

18 Ejemplo public interface Ordenable { public int comparar(Ordenable o); } class ClaseA implements Ordenable { //... Otras declaraciones... public int comparar(Ordenable o) { // compara } class ClaseB implements Ordenable { //... Otras declaraciones... public int comparar(Ordenable o) { // compara } class Sorter { //... Otras declaraciones... public void shell_sort(Sortable[] a) {....} public void quick_sort(Sortable[] a) {....} public void bubble_sort(Sortable[] a) }

19 Protocolo “ El protocolo de una clase está formado por el conjunto de aquellos mensajes que puede responder”

20 Polimorfismo Desde el punto de vista del receptor:  Es la capacidad de diferentes objetos de responder de diferente manera ante el mismo mensaje. Desde el punto de vista del emisor:  Es la capacidad para manipular objetos de diferentes clases solo en base al conocimiento de sus propiedades comunes, sin tener en cuenta la clase exacta a la que pertenecen.

21 Herencia Permite definir nuevas clases en base a clases ya existentes La subclase extiende la superclase, redefiniendo y/o agregando propiedades.

22 Principios de Diseño Orientado a Objetos

23 Principio de Apertura y Clausura “Las clases debieran estar abiertas para su extensión pero cerradas para su modificación”

24 Principio de Apertura y Clausura (cont.) Apertura para la extensión  La clase puede extenderse para funcionar de nuevas maneras Clausura para la modificación  El código fuente es inviolable: no puede modificarse

25 Ejemplo

26 class Circulo: public Figura { public: float radio; void DibujarCirculo(); }; enum TipoFigura {circulo, rectangulo}; class Figura { public: TipoFigura tipo; int x, y; }; class Rectangulo: public Figura { public: float largo; float ancho; void DibujarRectangulo(); };

27 typedef Figura* PunteroFigura; void Pantalla::DibujarFiguras(PunteroFigura lista[], int n) { int i; for(i = 0; i < n; i++) { Figura* fig = lista[i]; switch(fig->tipo) { case circulo: Circulo* C = (Circulo*)fig; C->DibujarCirculo(); break; case rectangulo: Rectangulo* R = (Rectangulo*)fig; R->DibujarRectangulo(); }

28

29 class Circulo: public Figura { public: float radio; virtual void Dibujar(); }; class Figura { public: int x, y; virtual void Dibujar() = 0; }; class Rectangulo: public Figura { public: float largo; float ancho; virtual void Dibujar(); };

30 typedef Figura* PunteroFigura; void Pantalla::DibujarFiguras(PunteroFigura lista[], int n) { int i; for(i = 0; i < n; i++) { Figura* fig = lista[i]; fig->Dibujar(); }

31 Principio de Apertura y Clausura (cont.) La abstracción es la clave!

32 Principio de Apertura y Clausura (cont.) Clausura estratégica  Es imposible lograr la clausura absoluta ante todo tipo de cambio  El diseñador debe seleccionar los cambios ante los que clausurar el diseño

33 Principio de Apertura y Clausura (cont.) “En vez de considerar que cosas podrían forzar un rediseño, considere que cosas quiere ser capaz de cambiar sin rediseñar”

34 Principio de Apertura y Clausura (cont.) Heurísticas derivadas  Todas las variables de instancia deben ser privadas  No utilizar variables globales  La comprobación de tipos en tiempo de ejecución (ej: RTTI o tags) es peligrosa  Diseñar hacia la interfaz, no hacia la implementación

35 Principio del Ocultamiento de la Información “Todos los detalles acerca de la implementación de una clase deben ser invisibles e inaccesibles desde el exterior de la misma”

36 ¿Para qué ocultar? El problema del Acoplamiento  Dificultad para entender las dependencias  Rigidez, Fragilidad, Inmovilidad Ventajas del Ocultamiento  Clara separación de interfaz e implementación  Mayor nivel de abstracción  Acceso controlado a la parte privada  Libertar para modificar la implementación

37 Dos principios derivados Principio de las Mínimas Interfaces Principio de las Interfaces Pequeñas

38 Principio de las Mínimas Interfaces “Cada clase debiera comunicarse con la menor cantidad posible de otras clases”

39 Ejemplo void Agenda::AniversariosDeHoy(Personas lista[], int n) { int i; for(i = 0; i < n; i++) { Persona* p = lista[i]; Fecha* f = P->darFechaNacimiento() if(f->esHoy()) { AgregarPersonaQueCumpleHoy(p); } };

40

41 void Agenda::AniversariosDeHoy(Personas lista[], int n) { int i; for(i = 0; i < n; i++) { Persona* p = lista[i]; if(p->CumpleHoy()) { AgregarPersonaQueCumpleHoy(p); } }; bool Persona::CumpleHoy() { return fechaNacimiento->esHoy(); }

42

43 Principio de las Interfaces Pequeñas “Si dos clases se comunican, debieran intercambiar la menor cantidad posible de información”

44 Ejemplo void AlgunaClase::HacerAlgoConUnTiempo(Tiempo t) { long horas, minutos, segundos; long horaEnSegundos; horas = t->DarHoras(); minutos = t->DarMinutos(); segundos = t->DarSegundos(); horaEnSegundos = horas * 3600 + minutos * 60 + segundos; Procesar(horaEnSegundos); }

45 void AlgunaClase:: HacerAlgoConUnTiempo(Tiempo* t) { long horaEnSegundos = t->DarHoraEnSegundos(); Procesar(horaEnSegundos); } long Tiempo::DarHoraEnSegundos() { return horas * 3600 + minutos * 60 + segundos; }

46 Principio de Substitución “Las funciones que usan referencias a instancias de una clase determinada, deben ser capaces de operar con objetos pertenecientes a las subclases sin saberlo”

47 Principio de Substitución (cont.) Dicho de otra forma:  Las subclases de una clase deben diseñarse de tal forma que sus instancias puedan intercambiarse libremente con instancias de la superclase

48 Ejemplo

49 class Rectangulo { private: long alto, largo; public: virtual void AsignarAlto(float a) { alto = a; } virtual float DarAlto() { return alto; } virtual void AsignarLargo(float l) { largo = l; } virtual float DarLargo() { return largo; } };

50 class Cuadrado: public Rectangulo { public: virtual void AsignarAlto(float a); virtual void AsignarLargo(float l) }; void AsignarAlto(float a) { Rectangulo::AsignarAlto(a); Rectangulo::AsignarLargo(a); } void AsignarLargo(float l) { Rectangulo::AsignarAlto(l); Rectangulo::AsignarLargo(l); }

51 void test(Rectangulo* r) { r->AsignarAlto(5); r->AsignarLargo(4); float superficie = r->DarAlto() * r->DarLargo(); if(superficie != 20) { MostrarError(); } void main() { Rectangulo* r = new Rectangulo; Cuadrado* c = new Cuadrado; test(r); // aquí funciona bien test(c); // AQUÍ DA ERROR!! }

52 Principio de Inversión de la Dependencia Las clases de alto nivel no debieran depender de las clases de bajo nivel; ambas debieran depender de abstracciones. Las abstracciones no debieran depender de los detalles; los detalles debieran depender de las abstracciones.

53 Ejemplo void Copiador::Copiar(Teclado* t, Impresora* i) { char c = t->LeerCaracter(); while(c != EOF) { i->EscribirCaracter(c); c = t->LeerCaracter() }

54 class Reader { public: virtual char LeerCaracter() = 0; } class Writer { public: virtual void EscribirCaracter(char c) = 0; }

55 void Copiador::Copiar(Reader* r, Writer* w) { char c = r->LeerCaracter(); while(c != EOF) { w->EscribirCaracter(c); c = w->LeerCaracter() }

56 Estratificación

57 Estratificación + Abstracción

58 Principio de la Segregación de las Interfaces “Los clientes de una clase no debieran ser forzados a depender de interfaces que no utilizan”

59 Principio de Segregación de las Interfaces (cont.) Fenómeno de las interfaces “gordas”

60 Principio de Segregación de las Interfaces (cont.) Solución:

61 Principio de Segregación de las Interfaces (cont.) En sintesis:  Diferentes clientes implican interfaces separadas

62 Ejemplo

63

64 Principio de la Dependencia Acíclica “La estructura de dependencias entre módulos debe ser un grafo acíclico dirigido”

65 Principio de la Dependencia Acíclica (cont.) Modulo:  Conjunto de clases relacionadas, que se puede tratar como una unidad.

66 Ejemplo

67

68

69 Patrones de Diseño

70 Tipos de Diseño Diseño rutinario  Resolución de problemas familiares, reusando soluciones previas. Diseño innovador  Búsqueda de nuevas soluciones a problemas nunca vistos.

71 Tipos de Diseñadores Diseñador experto  Puede discernir entre diseño rutinario o innovador.  Es capaz de generar nuevas soluciones, utilizando buenas prácticas Diseñador inexperto  Reinventa permanentemente la rueda, y no siempre de la mejor manera.  Trabaja a su mejor saber y entender.

72 ¿Cómo lograr que el diseñador inexperto se comporte de manera similar al experto, hasta que eventualmente se vuelva experto? Transmisión de la Experiencia !!

73 Patrones de Diseño (Design Patterns) Objetivo:  Capturar experiencia de diseño en forma tal que otros puedan reusarla efectivamente.

74 ¿Qué es un Pattern? “Cada Pattern describe un problema que ocurre una y otra vez en un cierto contexto y describe luego la solución a ese problema, expresada de manera que podamos usarla miles de veces de diferente manera cada vez” Christopher Alexander, 1977

75 Patterns: otra definición “Un pattern describe un problema de diseño particular y recurrente que aparece en un contexto específico, presentando un esquema genérico y bien probado para su solución, describiendo sus componentes constitutivos, sus responsabilidades y relaciones, y las maneras en las que colaboran” “Design Patterns: Elements of Reusable Object Oriented Software” Gamma, Helm, Johnson & Vlissides

76 Ejemplos ABM en aplicaciones de bases de datos Adapters

77 Elementos Esenciales de un Pattern Nombre Problema y Contexto de aplicación Solución  Aspectos estáticos (clases, sus roles, responsabilidades y relaciones)  Aspectos dinámicos (secuencia de colaboraciones) Consecuencias

78 Ejemplo: Pattern Observer Nombre:  Observer (Dependents, Publisher-Subscriber) Problema:  ¿Como mantener consistente un conjunto de objetos interdependientes? Aplicabilidad (Contexto)  Una objeto es “observado” por un conjunto de otras objetos  Cuando el objeto cambia, sus observadores deben ser notificados para que también cambien  Debe ser posible agregar nuevos tipos de observadores sin modificar la clase observada

79 Estructura de la Solución: Ejemplo: Pattern Observer

80 Participantes:  Subject: Conoce a sus Observers; muchos observers pueden observar a un mismo subject Provee de una interfaz para asociar Observers  Observer: Define la interfaz de notificación Ejemplo: Pattern Observer

81 Participantes (cont.)  ConcreteSubject: Envia las notificaciones a sus observers  ConcreteObserver: Mantiene referencias al ConcreteSubject Implementa la estrategia de actualización Ejemplo: Pattern Observer

82 Consecuencias:  Acoplamiento abstracto entre Observers y Subjects  Posibilidad de agregar o eliminar dinamicamente Observers a un Subject  Posibilidad de crear nuevos Observers sin modificar los Subjects  Posibilidad de actualizaciones inesperadas o en cadena Ejemplo: Pattern Observer

83 Características de los Patterns Se refieren a un problema recurrente y a su solución Documentan soluciones bien probadas, obtenidas con la experiencia Identifican y especifican abstracciones cuya significación es mayor que la de sus componentes individuales Proveen una fuente de vocabulario común Son un medio para documentar arquitecturas de software Permiten construir software con propiedades bien definidas (consecuencias bien definidas)

84 Catálogo de Patterns Patrones Creacionales  Abstract Factory, Builder, Factory Method, Prototype, Singleton Patrones Estructurales  Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy Patrones de Comportamiento  Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor

85 Pattern Languages “Un pattern language es un conjunto de patterns que forman un todo cohesivo” “Un pattern language es una colección estructurada de patterns, relacionados entre si para transformar necesidades y restricciones en una arquitectura” (Jim Coplien)

86 Categorías de Patterns Patterns Arquitecturales Patterns de Diseño Patterns de Codificación (Idioms)

87 Patrones Arquitecturales “Un pattern arquitectural expresa un esquema estructural global para un sistema de software. Provee un conjunto predefinido de subsistemas, especifica sus responsabilidades e incluye reglas y lineamientos para organizar las relaciones entre ellos” “Pattern Oriented Software Architecture: a System of Patterns” Buschmann, Meunier, Rohnert, Sommerland, Stal

88 Idioms “Un idiom es un pattern de muy bajo nivel, específico para un lenguaje de programación en particular; tanto que muchas veces no es posible trasladarlo a otro”

89 Ejemplos Getters/setters en Smalltalk Smart pointers y reference counting en C++ Implementación Contratos:  C++: clases con solo métodos abstractos  Smalltalk: uso de los mismos nombres  Java: construcción Interface

90 Extensión del concepto de Patterns Patterns para Dominios Específicos Patterns Organizacionales

91 “Los patterns organizacionales describen como estructurar organizaciones y proyectos, proveyendo el apropiado soporte a la gestión de proyectos de software”

92 Fuentes básicas de Información “Design Patterns” Gamma, Helm, Johnson, Vlissides “Pattern Oriented Software Architecture” Buschmann, Meunier, Rohnert, Sommerland, Stal Patterns Home Page:  http://st-www.cs.uiuc.edu/patterns/ Patterns Mailing Lists

93 Preguntas y Respuestas andres@bbs.frc.utn.edu.ar fcuenca@prominente.com.ar