diseño orientado a objetos principios y patrones utn facultad córdoba laboratorio de sistemas ing....
TRANSCRIPT
Diseño Orientado a Objetos
Principios y Patrones
UTN Facultad CórdobaLaboratorio de Sistemas
Ing. Fernando A. Cuenca
¿Qué es “mal diseño”?
• Rigidez: dificultad para introducir cambios.
• Fragilidad: efecto cascada.• Inmovilidad: reusabilidad
dificultosa.
Agenda
• Conceptos de Orientación a Objetos
• Principios de Diseño O-O• Reuso de experiencia: Patrones de
Diseño
Orientación a Objetos
Revisión de conceptos
¿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.
¿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.
Objetos: algunos ejemplos
Dominio del Problema Objetos
Operaciones comercialesArtículos, Facturas,Ventas, Compras, Clientes,Contratos, Créditos, etc.
Procesos industrialesOrden de Fabricación,Productos y piezas,Métodos, Máquinas, etc.
Redes de ComputadorasNodos, Enlaces,Protocolos, Dispositivos,Usuarios, Permisos, etc.
Caracterización de un Objeto
• Estado• Comportamiento• Identidad
Clases: dos visiones
• Plantilla (o template)Una Clase es la especificación o
descripción genérica de un conjunto de objetos
• Conjunto de instanciasUna Clase es un conjunto de objetos
que comparten características y comportamientos comunes
Clases vs. Objetos
• Objetoentidad individual
• ClaseEspecificación abstracta
• Todo Objeto es instancia de una Clase
Los Objetos colaboran entre si
• Visión antropomórficaobjetos como “entes vivos”
• Responsabilidades y ColaboracionesRelaciones de uso
• Relaciones estructuralesAgregación o Composición de Objetos
Mensajes
• La única forma de acceder a un objeto es enviándole un Mensaje.
• “Acceder”obtener información del objetosolicitar la realización de una acción
• El objeto está encapsulado
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.
Enviando mensajes
• Emisor y Receptor (cliente y servidor)
• Selector y Parámetros
• Método
Mensaje
Método
ObjetoReceptor
ObjetoEmisor
Agrupando métodos
• Contratos• Protocolo
Contratos
“Un contrato (o interfaz) define un conjunto cohesivo de requerimientos que un cliente puede hacer a un server.”
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
Ejemplopublic 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)}
Protocolo
“ El protocolo de una clase está formado por el conjunto de aquellos mensajes que puede responder”
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.
Herencia
• Permite definir nuevas clases en base a clases ya existentes
• La subclase extiende la superclase, redefiniendo y/o agregando propiedades.
Principios de Diseño Orientado a Objetos
Principio de Apertura y Clausura
“Las clases debieran estar abiertas para su extensión pero cerradas para su modificación”
Principio de Apertura y Clausura (cont.)
• Apertura para la extensiónLa clase puede extenderse para
funcionar de nuevas maneras
• Clausura para la modificaciónEl código fuente es inviolable: no
puede modificarse
CirculoradiodibujarCirculo
Figuratipoxy
Rectangulolargoanchodibujarrectangulo
Ejemplo
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();};
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();
}
}
}
Rectangulolargoanchodibujar
Circuloradiodibujar
Figuraxydibujar
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();};
typedef Figura* PunteroFigura;
void Pantalla::DibujarFiguras(PunteroFigura lista[], int n)
{
int i;
for(i = 0; i < n; i++)
{
Figura* fig = lista[i];
fig->Dibujar();
}
}
Principio de Apertura y Clausura (cont.)
La abstracción es la clave!
ClaseCliente ClaseServidorausa
ClaseCliente ServidorAbstracto
ServidorConcreto1 ServidorConcreto3
ServidorConcreto2
Principio de Apertura y Clausura (cont.)
• Clausura estratégicaEs imposible lograr la clausura
absoluta ante todo tipo de cambioEl diseñador debe seleccionar los
cambios ante los que clausurar el diseño
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”
Principio de Apertura y Clausura (cont.)
• Heurísticas derivadasTodas las variables de instancia deben
ser privadasNo utilizar variables globalesLa 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
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”
¿Para qué ocultar?
• El problema del AcoplamientoDificultad para entender las dependenciasRigidez, Fragilidad, Inmovilidad
• Ventajas del OcultamientoClara separación de interfaz e
implementaciónMayor nivel de abstracciónAcceso controlado a la parte privadaLibertar para modificar la implementación
Dos principios derivados
• Principio de las Mínimas Interfaces• Principio de las Interfaces
Pequeñas
Principio de las Mínimas Interfaces
“Cada clase debiera comunicarse con la menor cantidad posible de otras clases”
Ejemplovoid 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); } }};
PersonaAgenda
Fecha1
1
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();}
PersonaAgenda
Fecha1
1
Principio de las Interfaces Pequeñas
“Si dos clases se comunican, debieran intercambiar la menor cantidad posible de información”
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);}
TiempohorasminutossegundosdarHorasdarMinutosdarSegundos
void AlgunaClase:: HacerAlgoConUnTiempo(Tiempo* t){ long horaEnSegundos = t->DarHoraEnSegundos();
Procesar(horaEnSegundos);}
long Tiempo::DarHoraEnSegundos(){ return horas * 3600 + minutos * 60 + segundos;}
TiempohorasminutossegundosdarHorasdarMinutosdarSegundosdarHoraEnSegundos
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”
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
Ejemplo
Rectangulo
Cuadrado
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; }
};
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);}
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!!}
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.
Ejemplo
void Copiador::Copiar(Teclado* t, Impresora* i){ char c = t->LeerCaracter(); while(c != EOF) { i->EscribirCaracter(c); c = t->LeerCaracter() }}
Copiador
Teclado Impresora
class Reader{ public: virtual char LeerCaracter() = 0;}
class Writer{ public: virtual void EscribirCaracter(char c) = 0;}
DiscoScanner Impresora Pantalla
Copiador
Teclado
Reader Writer
void Copiador::Copiar(Reader* r, Writer* w){ char c = r->LeerCaracter(); while(c != EOF) { w->EscribirCaracter(c); c = w->LeerCaracter() }}
Estratificación
PoliticasGlobales
Utilidades de bajo nivel
Mecanismos intermedios
Estratificación + Abstracción
PoliticasGlobales Mecanismos abstractos
Utilidades abstractas
Utilidades de bajo nivel
Mecanismos intermedios
Principio de la Segregación de las
Interfaces“Los clientes de una clase no debieran ser forzados a depender de interfaces que no utilizan”
Principio de Segregación de las Interfaces (cont.)
• Fenómeno de las interfaces “gordas”
Clase CClase B
Clase A
Principio de Segregación de las Interfaces (cont.)
• Solución:
Clase B Contrato C Clase C
Clase A
Contrato B
Principio de Segregación de las Interfaces (cont.)
• En sintesis:Diferentes clientes implican
interfaces separadas
Ejemplo
InspectorPosicional InspectorDeFiguras
Diagrama
Diagrama
InspectorPosicional InspectorDeFiguras
InformadorDeFiguras InformadorPosicional
Principio de la Dependencia Acíclica
“La estructura de dependencias entre módulos debe ser un grafo acíclico dirigido”
Principio de la Dependencia Acíclica (cont.)
• Modulo:Conjunto de clases relacionadas, que
se puede tratar como una unidad.
Paquete B
Paquete A
Ejemplo
Aplicacion
Ventanasde Tareas
Utilidades
Tareas
Base deDatos
Cajas deDialogo
Ventanasde Mensajes
Ventanas
Ventanasde Tareas
Utilidades
Tareas
Base deDatos
Ventanasde Mensajes
Ventanas
Cajas deDialogo
Aplicacion
Clase X Clase Y
AplicacionCajas de Dialogo
Clase X
Clase Abstracta Y
Clase Y
AplicacionCajas de Dialogo
Patrones de Diseño
Tipos de Diseño
• Diseño rutinarioResolución de problemas familiares,
reusando soluciones previas.
• Diseño innovadorBúsqueda de nuevas soluciones a
problemas nunca vistos.
Tipos de Diseñadores
• Diseñador expertoPuede discernir entre diseño rutinario o
innovador.Es capaz de generar nuevas soluciones,
utilizando buenas prácticas
• Diseñador inexpertoReinventa permanentemente la rueda, y no
siempre de la mejor manera.Trabaja a su mejor saber y entender.
¿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 !!
Patrones de Diseño(Design Patterns)
• Objetivo:Capturar experiencia de diseño en
forma tal que otros puedan reusarla efectivamente.
¿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
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
Ejemplos
• ABM en aplicaciones de bases de datos
• Adapters
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
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
• Estructura de la Solución:
Ejemplo: Pattern Observer
ConcreteObserverUpdate()
Observer
Update()
Subject
Attach(Observer)Detach(Observer)Notify()
ConcreteSubject
SomeOperation() 1 1
11
En algun momento
Envia Update a todoslos Observers
• 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
• Participantes (cont.)ConcreteSubject:
• Envia las notificaciones a sus observers
ConcreteObserver:• Mantiene referencias al ConcreteSubject• Implementa la estrategia de actualización
Ejemplo: Pattern Observer
• Consecuencias:Acoplamiento abstracto entre
Observers y SubjectsPosibilidad de agregar o eliminar
dinamicamente Observers a un SubjectPosibilidad de crear nuevos Observers
sin modificar los SubjectsPosibilidad de actualizaciones
inesperadas o en cadena
Ejemplo: Pattern Observer
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)
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
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)
Categorías de Patterns
• Patterns Arquitecturales• Patterns de Diseño• Patterns de Codificación (Idioms)
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
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”
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 nombresJava: construcción Interface
Extensión del concepto de Patterns
• Patterns para Dominios Específicos• Patterns Organizacionales
Patterns Organizacionales
“Los patterns organizacionales describen como estructurar organizaciones y proyectos, proveyendo el apropiado soporte a la gestión de proyectos de software”
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
