diseño orientado a objetos principios y patrones utn facultad córdoba laboratorio de sistemas ing....

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

Preguntas y Respuestas

andres@bbs.frc.utn.edu.arfcuenca@prominente.com.ar