Tema 41 Programación Orientada a Objetos 3º de I.T.I.S. Departamento de Informática y Automática...

1

Programación Orientada a Objetos3º de I.T.I.S.

Departamento de Informática y AutomáticaUniversidad de Salamanca

Tema 4. Diseño Orientado a Objetos

Tema 4

Diseño Orientado a Objetos

Versión 6.0 – Marzo de 2004 © Francisco José García Peñalvo

2


Universidad de Salamanca – Departamento de Informática y Automática © Dr. Francisco J. García Peñalvo

ResumenEl diseño y posterior implementación de un sistema software bajo el paradigma orientado a objetos pasa por conocer las bases fundamentales con las que llevar a cabo las construcciones software, los elementos del modelo objeto y su soporte en algunos lenguajes de programación orientados a objetos. En la primera parte de este tema se hace un repaso por los elementos fundamentales del modelo objeto, pero con un enfoque más centrado en el diseño y en la implementación, para en una segunda parte aplicar estos conceptos en heurísticas y patrones de diseño.

Resumen

[Gamma et al., 2003][OMG, 2003][Stroustrup, 2002]

Bibliografía

Diseño orientado a objetos; Clase; Tipo; Objeto; Instancia; Atributo;Método; Herencia simple; Herencia múltiple; Polimorfismo; Asociación; Relación de uso; Agregación; Composición; Relación estructural; Relación funcional; Paquete; Espacio de nombres; Modularidad; Interfaz; Diseño para reutilización; Extensión del software; Relación tipo/subtipo; Patrón software (pattern); Patrón de diseño (design pattern); Patrón arquitectónico; Patrón de creación; Patrón estructural; Patrón de comportamiento

Descriptores

2




3



Esquema

1. Clases y tipos2. Métodos 3. Herencia4. Polimorfismo5. Asociaciones, agregaciones y composiciones 6. Interfaces7. Módulos

8. Principios de diseño orientado a objetos9. Introducción a los patrones de diseño10. Algunos patrones de diseño

11. Referencias12. Lecturas complementarias

Aspectos básicos

Aspectos avanzados

Complementos

4



1. Clases y tipos

3




5



1.1 Concepto intuitivo de clase (i)

Construcción estructural por excelencia en los sistemas orientados a objetosDescripción de objetos capaz de servir como molde para crear instancias o, lo que es lo mismo, objetos reales descritos por la clase

El proceso de creación de objetos se conoce como instanciación

Una clase dicta la estructura y comportamiento de sus instancias (objetos)Las instancias contienen localmente datos que se corresponden con la estructura dictada por la clase y que representa el estado del objeto

6



La estructura está dada por sus atributos y las operaciones por sus métodos, cada uno con su correspondiente signaturaPuestos en conjunto, los atributos y los métodos de una clase suelen recibir el nombre de recursos o propiedades de la claseTodos los objetos en un sistema de objetos pertenecen a alguna claseUna clase puede ser vista como

El mecanismo para crear objetosLa fábrica de objetosEl conjunto de todas sus instancias

Una clase es como una especie de contrato que vincula a una abstracción con todos sus clientesDistinción entre visión externa (interfaz) e interna (implementación) de la clase

1.1 Concepto intuitivo de clase (ii)

4




7



1.2 Definición de claseDescripción abstracta de los datos y del comportamiento de una colección de objetos similares [Budd, 1991]Descripción de un grupo de objetos con propiedades similares, comportamientos comunes, interrelaciones comunes y semántica común [Rumbaugh et al., 1991]Una clase es un tipo abstracto de datos equipado con una posible implementación [Meyer, 1997]Construcción lingüística en un lenguaje orientado a objetos. Las clases implementan tipos y son plantillas a partir de las cualesse crean objetos. Los objetos de la misma clase tienen estructura y operaciones comunes de acuerdo a la definición de la clase [Crespo, 2000]

8



1.3 Clases y tipos (i)Las clases implementan tipos y por tanto ayudan a la clasificación al nivel de un lenguaje orientado a objetos [Liskov, 1987]En muchos casos, una clase se corresponde directamente con un tipo, pero esto no siempre se cumple

En C++ una clase es un tipo definido por el usuarioEn Java, un tipo puede ser un tipo primitivo o una referencia a un tipo basada en una clase, una interfaz o una matrizEiffel no equipara los dos conceptos; cada tipo debe estar basado en una clase. En Eiffel todos los tipos, incluso los primitivos y las matrices, se derivan de clases

Mientras que un usuario puede definir tipos como clases, los dos conceptos no son equivalentes porque se pueden derivar múltiples tipos de una clase mediante la genericidad

Las clases siempre implementan tipos implícita o explícitamenteMuchas veces se dice que la clase es una forma especial de tipoEsto significa que para toda clase existe una especificación de tipo que caracteriza al conjunto de las instancias potenciales de la claseLa extensión de dicho tipo se correspondería con el conjunto de instancias potenciales de la clase

5




9



Una clase puede tener parámetros formales que se usan para definir módulos paramétricos o genéricos (Clases Genéricas o Paramétricas)

Una clase paramétrica es la implementación de una familia de tipos

Desde el punto de vista de los programadores, los tipos y las clases son elementos diferentes, debido a que la información del tipo sólo ofrece la especificación de un objetoLas clases describen especificaciones que pueden ser compartidasentre colecciones de objetos u otras clases, no sólo entre objetos con una única entidad, o instanciasDesde el punto de vista de los analistas, las clases y los tipos abstractos de datos son, en efecto, lo mismo [Graham, 1994]

1.3 Clases y tipos (ii)

10



1.3 Clases y tipos (iii)

Como conclusión, en la programación orientada a objetos un tipo y una clase no son exactamente

lo mismo, considerándose a los tipos como la puesta en vigor de la clase de los objetos,

de modo que los objetos de distinto tipo no pueden intercambiarse o, como mucho, pueden

hacerlo sólo de formas muy restringidas

[Booch, 1994]

6




11



Ejemplos de definición de clases

Ventana

Ventana

Tamaño: Áreavisibilidad: Lógico

display ()hide ()

+tamaño: Área =(100,100)#visibilidad: Lógico= invisible+tamaño-por-defecto: Rectángulo

#tamaño-máximo: Rectángulo-xptr: XWindows*

+display ()+hide ()+create ()-attrachXWindow(xwin:Xwindows*)

Ventana{abstract,autor=Joseestado=comprobada}

1.4 Clases y objetos en UML (i)

Ejemplos de definición de objetos

MiVentana :Ventana[OMG, 2003]

12



Atributos (i)Se utilizan para describir los atributos de las clasesEl tipo de un atributo puede ser simple o complejoLa notación de los atributos es

visibilidad nombre:tipo de expresión=valor inicial {cadena de propiedades}

Visibilidad: Expresa si los atributos son visibles a otros objetos

+ Visibilidad Pública# Visibilidad Protegida- Visibilidad Privada

Nombre: Es una cadena que sirve para identificar al atributo

La expresión de tipo: Indica el tipo o dominio del atributo

El valor inicial: Este elemento es opcional, (en cuyo caso se omite el signo igual)

La cadena de propiedades: Indica los valores de las propiedades de un elemento

1.4 Clases y objetos en UML (ii)

7




13



Atributos (ii)

Un atributo con alcance de clase, es decir, un atributo común a todas las instancias de la clase, se expresa a través de una cadena subrayada Un atributo con alcance de instancia no se subraya por defecto

atributo de alcance de la clase

+ Tamaño:Area=(100,100)# visibilidad:Lógica=invisible+ Tamaño-por-defecto:Rectángulo# Tamaño-máximo:Rectángulo- xptr:XWindow*

1.4 Clases y objetos en UML (iii)

14



Métodos

Se utilizan para indicar las operaciones o métodos de una claseNotación similar a los atributos

visibilidad nombre (lista de parámetros): expresión del tipo de retorno {cadena de propiedades}

Las operaciones se suelen expresar en minúscula, (primera letra incluida)Una operación con alcance de clase se presenta subrayadaSi la operación es abstracta, es decir, todavía no se ha implementado, se acostumbra a mostrar en cursiva

+ muestra():Localización+ oculta()+ crea()- attachXWindow(xwin:XWindow*)

1.4 Clases y objetos en UML (iv)

8




15



La unidad fundamental de programación en java es la claseLas clases

Contienen los métodos (código ejecutable)Proporcionan la estructura de los objetosProporcionan el mecanismo para fabricar objetos a partir de las definiciones de la clase

Cada objeto es una instancia de la claseLos elementos fundamentales de una clase son los atributos y los métodosSeparación entre el qué y el cómo

El qué es el conjunto de métodos (y datos) de acceso público y su semánticaEl cómo de un objeto viene dado por su clase, que define la implementación de los métodos que soporta el objeto

1.5 Clases y objetos en Java (i)

16



class nombre_de_clase {tipo variable_de_instancia1;tipo variable_de_instancia2;...tipo variable_de_instanciaN;

tipo nombre_de_método1 (lista_de_parámetros) {cuerpo_del_método;

}tipo nombre_de_método2 (lista_de_parámetros) {

cuerpo_del_método;}...tipo nombre_de_métodoN (lista_de_parámetros) {

cuerpo_del_método;}

}

Plantilla básica de una clase Java

1.5 Clases y objetos en Java (ii)

9




17



El archivo fuente es la unidad de compilación javaArchivo de texto con una o más definiciones de clase (no hay ni funciones ni variables globales)Estos ficheros tienen extensión .java

Cuando se compila el código fuente, cada clase individual se coloca en un fichero de salida propio con el nombre de la clase con extensión .classUna aplicación Java debe tener una clase que contenga un método main con el que poder iniciar el programa

El compilador de Java compilará todas las clases que no tengan un método mainEl intérprete de Java, sin embargo, no tiene modo alguno de ejecutar esas clasesEl fichero fuente y la clase con el método main deben tener el mismo nombre (incluyendo mayúsculas y minúsculas)

1.5 Clases y objetos en Java (iii)

18



Creación de objetosCada clase que se crea añade otro tipo que puede utilizarse igual que los tipos simplesCuando se declara una nueva variable se puede utilizar un nombrede clase como tipo

A estas variables se las denomina referencias a objeto

Todas las referencias a objeto son compatibles también con las instancias de subclases de su tipo declaradoCuando se declara que el tipo de una variable es una clase, tiene como valor por defecto null

Empleado emp;El operador new crea una única instancia de una clase y devuelve una referencia a ese objeto

Empleado emp = new Empleado ( );Aquí emp es una referencia a una instancia de Empleado

1.5 Clases y objetos en Java (iv)

10




19



Control de accesoTodos los atributos y métodos de una clase son accesibles para el código de la propia clasePara controlar el acceso de otras clases (así como la herencia por las subclases), los miembros de una clase tienen unos modificadores de control de acceso

public: Los miembros declarados como públicos son accesibles en cualquier lugar donde sea accesible la clase (y son heredados por las subclases)private: Los miembros declarados como privados son accesible sóloen la propia claseprotected: Los miembros declarados como protegidos son accesibles para las subclases y heredados de ellas, así como por el código del mismo paquete

Los miembros que se declaren sin modificador son accesibles sólo para el código y heredados sólo por las subclases del mismo paquete

1.5 Clases y objetos en Java (v)

20



1.6 Descubrimiento de Clases

Técnicas de identificación de clasesAproximaciones lingüísticas [Abbott, 1983]Tarjetas CRC [Beck y Cunningham, 1989], [Wirfs-Brock, et al., 1990]Casos de uso [Jacobson, 1987], [Jacobson et al., 1992]

“... la identificación de objetos se reconoce como una clave, posiblemente como la clave, el cuello de botella al aplicar

tanto el diseño como el análisis orientados al objeto”

Ian Graham (1994)

11




21



CRC (Class, Responsability and Collaboration - Clases, Responsabilidades, y Colaboraciones)Técnica propuesta inicialmente por Beck y Cunningham (1989)Popularizadas por Rebecca Wirfs-Brock [Wirfs-Brock et al., 1990] También reciben el nombre de fichas o tarjetas de claseConstituyen una forma simple y efectiva de analizar escenariosHerramienta de desarrollo extremadamente útil que favorecela tormenta de ideas y contribuye a la mejora de la comunicación entre los desarrolladoresHerramientas para su construcción: CRC CASE http://tejo.fis.usal.es/~fgarcia/docencia/isoftware/case/CRCCASE.htm

1.6.1 Tarjetas CRC Introducción (i)

22



Consiste en elaborar por cada clase una tarjeta, en la que se anotan

El nombre de la claseLa lista de sus superclasesLa lista de sus subclasesSus responsabilidadesSus colaboradores

Clase: nombre de la clase (Abstracta o concreta)

Lista de superclases

Lista de subclases

Responsabilidad Colaboración

1.6.1 Tarjetas CRC Introducción (ii)

12




23



1.6.1 Tarjetas CRC Introducción (iii)

24



Las responsabilidades de un objeto son todos los servicios que proporciona para todos los contratos que soportaLas responsabilidades sólo determinan en una primera fase qué acciones deben llevarse a cabo, pero no cómo

Responsabilidades

Las colaboraciones representan peticiones por parte de un clientea los servidores para el cumplimiento de las responsabilidades del clienteLa relación entre las colaboraciones y las responsabilidades no es de tipo 1:1

1.6.1 Tarjetas CRC Introducción (iv)

Conocimiento que tiene la clase

Acciones que puede realizar un objeto de la misma

13




25



1.6.1 Tarjetas CRC Características

Independencia de la máquinaIndependencia del lenguajeFáciles de copiarInterfaz intuitivaFísicasBaratas

26



Permiten identificar las clases y validarlas “jugando” con las tarjetas, examinando cómo una clase envía mensajes a otra y cuáles son sus responsabilidades para comprobar si posee todas las características

necesarias para atender las peticiones que le llegan

Cuando se han identificado los servicios, se agrupan en contratos. Una responsabilidad puede ser parte como mucho de un contrato, pero no

toda responsabilidad debe formar parte de un contrato

ES UN PROCESO DE CONSTRUCCIÓN ITERATIVO

Identificar clases y responsabilidades

Asignar responsabilidades

Identificar colaboraciones

1.6.1 Tarjetas CRC Construcción (i)

14




27



Diseño de las responsabilidades

Distribuir la inteligencia de forma pareja

Determinar las responsabilidades de la manera más general posible

Mantener el comportamiento con la información relacionadacon el mismo

Agrupar las responsabilidades utilizadas por los mismos clientes

Maximizar la cohesión de las clases

Minimizar el número de contratos

1.6.1 Tarjetas CRC Construcción (ii)

28



Vocabulario de proyecto común

Extensión del conocimiento del dominio

Facilitar el cambio de paradigma

Prototipado vivo

Identificación de los fallos en los requisitos

1.6.1 Tarjetas CRC Ventajas

15




29



1.7 Diseño de clases (i)

Tipos de clases [Budd, 1991]Clases de manejadores de datos, de datos o de estado. Su responsabilidad principal es mantener informaciónPozos de datos o fuentes de datos. Clases que generan datos. No retienen datos por un período, sino que los generan o procesan por demandaClases de vista u observadoras. El código para presentar la información en un dispositivo de salida es complejo y cambiante. Es una buena práctica aislar el comportamiento de presentación en clases separadas de aquéllas que guardan los datos a mostrarClases auxiliares o de ayuda. Guardan poca o ninguna información del estado por sí mismas. Asisten en la ejecución de tareas complejas

30



Errores comunes en el diseño de clases [Budd, 1991]Clases que hacen modificaciones directas a otras clasesClases con demasiada responsabilidadClases sin responsabilidadClases con responsabilidades que no se usanNombres engañososResponsabilidades desconectadasUso inadecuado de la herenciaFuncionalidad repetida

1.7 Diseño de clases (ii)

16




31



2. Métodos

32



2.1 Concepto intuitivoLas clases en OO no son simples registros de datos, sino que se encapsulan junto a los datos las unidades funcionales necesarias para actuar sobre los datosUn mensaje es simplemente una operación que un objeto realiza sobre otroUn método es el procedimiento o función que se invoca para actuar sobre un objeto

Un método especifica cómo se ejecuta un mensaje

Las operaciones que los clientes pueden realizar sobre un objeto suelen declararse como métodos, que forman parte de la declaración de la claseEl conjunto de mensajes a los que puede responder un objeto se denomina protocolo del objeto

17




33



2.2 Definición

Operación sobre un objeto, definida como parte de la declaración de una clase; todos los métodos son operaciones, pero no todas las operaciones son métodos. Los términos mensaje, método y operación suelen ser equivalentes [Booch, 1994] Es el algoritmo ejecutado en respuesta a la recepción de un mensaje cuyo nombre se corresponde con el nombre del método [Joyanes, 1998]En Smalltalk, las operaciones se llaman métodos. En UML, un método se define como la implementación de una operación. En la práctica, el uso de método y operación como sinónimos no es crítico [Oestereich, 1999]

34



2.3 Tipos de métodos

Se pueden distinguir cinco tipos de operaciones básicas [Booch, 1994]Modificador: Una operación que altera el estado de un objeto

Selector: Una operación que accede al estado de un objeto, pero no altera ese estado

Iterador: Una operación que permite acceder a todas las partes de un objeto en algún orden perfectamente establecido

Constructor: Una operación que crea un objeto y/o inicia su estado

Destructor: Una operación que libera el estado de un objeto y/o destruye el propio objeto

18




35



Las funciones miembro es un concepto de C++ equivalente al concepto de métodoEn la declaración de una clase deben aparecer los prototipos de las funciones miembroLas definiciones de las funciones miembro pueden estar

En línea (dentro de la clase) En el mismo fichero, pero fuera de la claseEn otro fichero diferente

Para referenciar a una función miembro dentro de la misma clase se utiliza el nombre de la funciónLa referencia a una función miembro fuera de la clase se hace utilizando el operador ::

NombreClase::NombreMétodoEl operador :: se puede utilizar para seleccionar otra definición que no sea la que se toma por omisión

2.4 Métodos en C++ (i)

36



#include <stdio.h>#include <iostream.h>

class Ejemplo {public: // Sección pública

void puts( char * texto );};

void Ejemplo::puts (char *texto){::puts ("Se está utilizando la función puts() de stdio.h\n");cout << texto << endl;

}

void main (void){Ejemplo A;

A.puts("Utilizando la función Ejemplo::puts()");}

2.4 Métodos en C++ (ii)

19




37



2.4.1 Tipos de funciones miembro en C++Funciones miembro simplesFunciones miembro estáticasFunciones miembro constFunciones miembro volatileFunciones miembro inlineFunciones miembro const thisFunciones miembro volatile thisFunciones virtualesConstructoresDestructorFunciones operadorFunciones amigas

38



2.4.2 Métodos inline (i)

Las funciones miembro pueden ser inlineUtilizando la palabra reservada inline en la definición de la funciónDefiniendo la función dentro de la definición de la clase

Son tratadas de forma similar a las macros (expansión en línea)Es una solicitud al compiladorSólo se pueden utilizar funciones en línea en el fichero en que están definidas

20




39



2.4.2 Métodos inline (ii)#include <iostream.h>#include <math.h>

class Complejo {float real, // Parte real

imag; // Parte imaginariapublic:

void MuestraComplejo(void) { // Es inline por definirla en la clasecout << real ;(imag<0) ? cout << " - " : cout << " + ";cout << fabs(imag) << "i" << endl;

}void PideComplejo(void);

};inline void Complejo::PideComplejo(void) { // Es inline porque se ha forzado

cout << "Parte real: ";cin >> real;cout << endl << "Parte imaginaria: ";cin >> imag;

}void main(void) {

Complejo I;I.PideComplejo();I.MuestraComplejo();

}

40



2.4.3 Constructores (i)

En C++ una forma de asegurar que los atributos de los objetos contiene valores válidos en el momento de su construcciónSirve para construir un nuevo objeto y asignar valores a sus atributos

Un constructor es una función miembro de la clase, que tienela misión principal de iniciar los atributos de la instancia a la

vez que reserva el almacenamiento necesario en memoria parala instancia

21




41



Características Tiene el mismo nombre que la clase en que está definidoPuede definirse inline o fuera de la declaración de la clasePuede aceptar argumentosPuede estar sobrecargado

Se puede declarar más de un constructor para una misma clase si todos ellos tienen diferente lista de argumentosEsto es útil si se quiere iniciar los objetos de varias formas diferentes. Pero también se debe tener en cuenta que un constructor puede no existir

No se puede especificar un valor de retornoEn consecuencia un constructor no puede tener ninguna sentencia return

Se ejecuta de forma automática cuando se crea un objeto de tipo clase. No se invoca de forma explícitaSuele estar declarado en la sección públicaNo puede declararse ni static ni virtualNo es obligatorio definir constructores, aunque es una buena técnica de programación hacerloSe denomina constructor por defecto de la clase al constructor que no tiene argumentos

2.4.3 Constructores (ii)

42



Ejemplos sencillosclass Pila {

int tabla[10];int cima;

public:void meter (int n);int sacar(void);Pila(void) {cima=0;}

};

class Circulo {int centro_x, centro_y;double radio;

public:Circulo(int x, int y, double r){

radio = r;centro_x = x;centro_y = y;

}// Otros métodos ...};

2.4.3 Constructores (iii)

class Prueba {int a, b;

public:Prueba(int i, int j=20);

};

Prueba::Prueba(int i, int j){a=i;b=j;

}

class P {dato d1, d2, d3;public:P(dato x1, dato x2, dato x3):d1(x1), d2(x2), d3(x3) { }...

};

22




43



class Complejo {float real, // Parte real

imag; // Parte imaginariapublic:

void MuestraComplejo(void);

void PideComplejo(void);

Complejo() {real = imag = 0.0;}

Complejo(float r, float i = 0.0) { real = r; imag = i;}};

void main(void) {Complejo I;Complejo J(1);Complejo K(1,1);

I.MuestraComplejo();J.MuestraComplejo();K.MuestraComplejo();

}

2.4.3 Constructores (iv)

44



#include <iostream.h>

class Prueba {int a1, a2, a3;// Se declara un constructor privado// Sólo será accesible desde objetos declarados en funciones miembro Prueba(int x, int y, int z) {a1=x; a2=y; a3=z;}

public:Prueba() {a1=0; a2=0; a3=0;}void Muestra(void) {cout << a1 << " " << a2 << " " << a3 << endl;}void Priv (int t0, int t1, int t2) {

Prueba O1(t0, t1, t2);// Utiliza el constructor privadoO1.Muestra();

}};void main (void) {

Prueba O1; // Utiliza el constructor por defecto públicoO1.Muestra(); // Saca 0 0 0O1.Priv(1,2,3); // Saca 1 2 3

}

2.4.3 Constructores (v)

23




45



Este constructor recibe como único argumento una referencia a un objeto de la misma claseEl compilador crea por defecto un constructor copia si no se crea explícitamente uno para la claseEl constructor copia realiza una copia bit a bit del objeto fuente en el nuevo objeto

Se denomina constructor copia a aquel constructor que creaun nuevo objeto, iniciándolo con los datos tomados de otro

objeto ya existente

2.4.4 Constructor copia (i)

46



El constructor copia por defecto funciona de forma correcta en la mayoría de los casos, aunque existen excepciones en las que el constructor copia por defecto dará problemas

Cuando no hay punteros, no hay problemas, pudiéndose utilizar el constructor copia por defectoSi hay punteros, el constructor copia por defecto iniciará un puntero con la dirección de otro puntero, y esto es una fuente de errores

Los constructores copia tienen una gran importancia en C++ debido a

Son el único medio de realizar una copia de un objetoSe emplean cuando se pasan objetos por valor a una funciónSe emplean cuando una función devuelve un objeto

2.4.4 Constructor copia (ii)

24




47



#include <iostream.h>class MC {

float m,n,o,p;public:

MC () { // Constructor 1m=n=o=p=0.0;

}MC (float i) { // Constructor 2

m=n=o=p=i;}MC (const MC & fuente) { // Constructor copia

m=fuente.m;n=fuente.n;o=fuente.o;p=fuente.p;

}void Cambiar(float a=0.0, float b=0.0, float c=0.0, float d=0.0);void Escribir(void);

};

2.4.4 Constructor copia (iii)

// Funciones miembrovoid MC::Cambiar(float a, float b, float c, float d) {

m=a; n=b;o=c; p=d;

}void MC::Escribir(void) {

cout << "\nValor de m: " << m;cout << "\nValor de n: " << n;cout << "\nValor de o: " << o;cout << "\nValor de p: " << p << "\n";

}

48



// Programa Principalvoid main (void){

MC o1(3), // La primera instancia utilizará el constructor 2o2, // La segunda instancia utilizará el constructor 1o3(o1); // La tercera utilizará el constructor copia

o1.Escribir(); // Saca m=n=o=p=3o2.Escribir(); // Saca m=n=o=p=0o3.Escribir(); // Saca m=n=o=p=3

o3.Cambiar(5,6,7,8); // Cambiamos los valores del objeto 3

MC o4(o3); // Una nueva instancia de MC, utiliza el constructor copia

o4.Escribir(); // Saca por pantalla m=5, n=6, o=7, p=8

MC o5=o4; // Utiliza el constructor copia

o5.Escribir(); // Saca por pantalla m=5, n=6, o=7, p=8}

2.4.4 Constructor copia (iv)

25




49



2.4.5 Destructores (i)

Es la contrapartida del constructorLas operaciones que suele llevar a cabo un destructor suelen estar relacionadas con la limpieza del espacio de trabajoSi no se define un destructor, el compilador generará uno de forma automática

Un destructor es una función miembro de la clase que sellama de forma automática cuando el objeto sale del ámbito

en el que fue definido, con el fin de realizar operaciones específicas antes de destruir el objeto

50



Características Tiene el mismo nombre que la clase en la que está definido, pero va precedido del carácter ~El destructor se llama automáticamente cuando el objeto sale fuera del ámbitoA diferencia de un constructor, un destructor no puede aceptar argumentos y, por tanto, no puede estar sobrecargadoCada clase tiene como máximo un destructorNo pueden tener valor de retornoLos destructores pueden ser virtualesSe pueden definir dentro y fuera de la claseSe suelen declarar en la sección públicaAunque no es lo habitual, se pueden llamar de forma explícita

2.4.5 Destructores (ii)

26




51



#include <iostream.h>#include <stdlib.h>

void error(char *msg);

class Vector {int *vector;int sz;

public:Vector(int); // Constructor~Vector(); // Destructorint Size(void) { return sz; }void IntroduceValor(int, int);int LeeValor(int);

};

Vector::Vector(int s) {if (s<=0)

error("\nTamaño de vector erróneo\n");sz=s;vector=new int[s];cout << "\nConstructor ejecutado con éxito\n";

}

2.4.5 Destructores (iii)

52



Vector::~Vector() {delete [] vector;cout << "\nDestructor ejecutado con éxito\n";

}

void Vector::IntroduceValor(int indice, int valor) {vector[indice]=valor;

}

inline int Vector::LeeValor(int indice) {return vector[indice];

}

void error(char *msg) {cerr << msg;exit(-1);

}

2.4.5 Destructores (iv)

void main(void) {Vector v(25); // Instancia de la clase vector

for (register int i=0; i < v.Size(); i++) {v.IntroduceValor(i, i*2);

cout << v.LeeValor(i) << " ";}cout << "\n";

{Vector x(7); // Instancia de la clase vector} // Se destruye el objeto x

} // Se destruye el objeto v

27




53



2.4.6 Métodos que retornan referencias (i)

Pueden existir funciones miembro que se comportan como si fueran atributos públicosEstas funciones retornan referencias a los miembros dato privadosEs una mala técnica de programación porque viola el encapsulamiento

54



#include <iostream.h>inline int max(int a, int b);inline int min(int a, int b);

class Fecha {int mes, dia, agno;

public:Fecha(int m, int d, int a);int &Mes(void);int GetMes() {return mes;}

};

Fecha::Fecha(int d, int m, int a) {dia=d; mes=m; agno=a;

}

int &Fecha::Mes(void) {mes=max(1,mes);mes=min(mes, 12);

return mes;}

2.4.6 Métodos que retornan referencias (ii)

inline int max(int a, int b) {if (a>b) return a;return b;

}inline int min(int a, int b) {

if (a<b) return a;return b;

}void main(void) {

Fecha nacimiento(9,7,1971);

cout << nacimiento.Mes() << endl;nacimiento.Mes()=4;cout << nacimiento.Mes() << endl;cout << ++nacimiento.Mes() << endl;cout << nacimiento.GetMes() << endl;

}

28




55



ConclusionesLa sintaxis es confusa, especialmente para aquéllos que lean el programaLa comprobación del rango se lleva a cabo cada vez que el dato miembro es leído, y esto no es eficienteViola el encapsulamiento al convertir un atributo privado en público

2.4.6 Métodos que retornan referencias (iii)

56



2.4.7 Objetos constantes y métodos (i)

Se pueden definir objetos constantesEsto significa que ninguno de los atributos del objeto puede variar su valorNo se permite el uso de funciones miembro con objetos constantesSe pueden declarar métodos de sólo lectura

29




57



#include <iostream.h>class Fecha {

int mes, dia, agno;public:

Fecha(int m, int d, int a);

int LeeDia(void) const;int LeeMes(void) const;int LeeAgno(void) const;

void EscribeDia(int d);void EscribeMes(int m);void EscribeAgno(int a);

void MuestraFecha(void) const;};

2.4.7 Objetos constantes y métodos (ii)Fecha::Fecha(int d, int m, int a) {

dia=d; mes=m; agno=a;}inline int Fecha::LeeDia(void) const {

return dia;}inline int Fecha::LeeMes(void) const {

return mes;}inline int Fecha::LeeAgno(void) const {

return agno;}inline void Fecha::EscribeDia(int d) {

dia=d;}inline void Fecha::EscribeMes(int m) {

mes=m;}inline void Fecha::EscribeAgno(int a) {

agno=a;}inline void Fecha::MuestraFecha(void) const {

cout << dia << "/" << mes << "/" << agno << "\n";}void main(void) {

const Fecha nacimiento(9,7,1971);

nacimiento.MuestraFecha(); // Correcto

// nacimiento.EscribeMes(10); // Error

cout << nacimiento.LeeMes(); // Correcto}

58



2.4.8 Punteros a métodosEs posible obtener la dirección de un método de una claseSe obtienen aplicando el operador & a un nombre cualificado de un método de una clase &nombre_clase::nombre_método

#include <iostream.h>class p {

char *valor;public:

p(char *c) {valor = c;}void print (int a) { cout << valor << a << endl;}

};void main(void) {

void (p::*ptr) (int);

p a1("a1 ");p a2("a2 ");p *pa = &a2;ptr = &p::print;

a1.print(1);(a1.*ptr) (2);a2.print(3);(pa->*ptr) (4);

}

30




59



2.4.9 Miembros estáticos (i)

Cada vez que se tiene una instancia de una clase, los atributos se duplicanSi se desea que el espacio creado en diferentes objetos para un atributo sea el mismo, debe declararse estático (static)El atributo estático existe aunque no haya instancias de la claseA un atributo estático se le asigna una zona fija de almacenamiento, al igual que una variable global, pero el identificador de la variable estádentro de ámbito utilizando sólo el operador de resolución con el nombre de la clasePueden declararse privados o públicosSe puede acceder a ellos de tres formas

Utilizando el operador punto (.)Utilizando el operador ->, si el lado del izquierdo es un puntero a objetoUtilizando el identificador de la clase sin referenciar un objeto real

Atributos estáticos

60



class Cuenta {char nombre[50];float total;static float incremento;

public:Cuenta ();void Interes() { total += incremento*total;}

};

nombre nombre nombre

total total total

Pepe Pérez Antonio López Ana Sánchez

4000.0 54000.0 46000.0

incremento 0.005

2.4.9 Miembros estáticos (ii)

31




61



#include <iostream.h>#include <string.h>


public:Cuenta (char *cad, float t) {

strcpy(nombre, cad);total = t;

}void Interes() { total += incremento*total;}void Datos() {cout << nombre << " " << total << endl;}

};

float Cuenta::incremento = 0.005;

2.4.9 Miembros estáticos (iii)

void main (void) {Cuenta c1("Pepe Pérez", 409540);Cuenta c2("Ana Toro", 548343);

c1.Datos();c2.Datos();

// c1.incremento = 0.453; // Error// Cuenta::incremento = 0.343; // Error

c1.Interes();c2.Interes();


}

62




class Cuenta {char nombre[50];float total;

public:Cuenta (char *cad, float t) {

strcpy(nombre, cad);total = t;

}void Interes() { total += incremento*total;}void Datos() {cout << nombre << " "

<< total << endl;}

static float incremento;};float Cuenta::incremento = 0.005;

2.4.9 Miembros estáticos (iv)

void main (void) {Cuenta c1("Pepe Pérez", 409540);Cuenta c2("Ana Toro", 548343);


c1.incremento = 0.453;

c1.Interes();

Cuenta::incremento = 0.343;c2.Interes();


}

32




63



#include <iostream.h>class Obj{

static int numero;public:

Obj() { numero++;}

~Obj() { numero--;}

void Estado(){cout << "\nHay " << numero << " objeto";(numero==1) ? cout << " " : cout << "s ";cout << "en la clase.\n";

}};int Obj::numero=0;void main (void) {

Obj A, B, C;A.Estado();B.Estado();C.Estado();{Obj D;D.Estado();}C.Estado();

}

2.4.9 Miembros estáticos (v)

VentajasReducen la necesidad de variables globalesHacen evidentes los datos que pueden ser compartidos dentro de una clase

64



Se pueden definir métodos estáticosEstos métodos sólo pueden acceder a otros métodos y atributos estáticosUna función miembro estática puede manejar variables globales

2.4.9 Miembros estáticos (vi)

Métodos estáticos

33




65




public:Cuenta ();void Interes() { total += incremento*total;}static void ActualizaIncremento(float v) {

incremento = v;}

};

void main(void) {Cuenta micuenta;micuenta.ActualizaIncremento(0.0002);Cuenta::ActualizaIncremento(0.3423);

}

2.4.9 Miembros estáticos (vii)

66




int v1, v2=1, v3=2;

class Prueba {static int incremento;

public:static void suma(void) { v1=v2+v3+incremento;}

};

int Prueba::incremento=5;

void main (void) {Prueba::suma();cout << v1 << endl;

}

2.4.9 Miembros estáticos (viii)


int v1, v2=1, v3=2;

class Prueba {static int incremento;

public:static void suma(void) { v1=v2+v3+incremento;}

};int Prueba::incremento=5;

void main (void){void (*pf)()=&Prueba::suma;

(*pf)();

cout << v1 << "\n"; // Saca 8 por pantalla}

34




67



3. Herencia

¿¿ A quién habrásalido esta niña ??

68



3.1 Introducción (i)La noción de herencia tiene sus raíces en el estudio de la inteligencia artificial: marcos, redes semánticasLa relación de herencia en la programación orientada a objetos tiene un significado análogo a su sentido usual que se hace familiar a todo el mundo

La herencia es la adquisición de propiedades de generaciones anteriores

En el contexto de la orientación a objetos, la herencia permite a nuevas descripciones de objetos basarse en descripciones existentes

Cuando una nueva clase de objetos se define a partir de otras mediante herencia, sólo se necesita declarar de forma explícita las propiedades en las que difiere de las clases existentes, tomando el resto de éstas automáticamente

35




69



La herencia es una relación entre clases en la que una clase comparte la estructura y/o el comportamiento definidos en una (herencia simple) o más clases (herencia múltiple) [Booch, 1994]Los términos hijo y padre, derivada y base, subclase y superclase se utilizan para nombrar a una clase que hereda de otra y a esta última, respectivamenteLa herencia es transitiva [Marqués, 1995]

Ancestros y descendientes

Dos formas de utilización de la herencia [Sakkinen, 1989]Herencia Esencial: se corresponde con implementar relaciones de subtipo a través de la herenciaHerencia Incidental: la herencia incidental, también llamada herencia de reutilización o de compartición de código

3.1 Introducción (ii)

70



3.2 Herencia múltiple (i)Herencia simple es el tipo de herencia por la que una

clase sólo puede tener una superclase [Rumbaugh et al., 1991]

Herencia múltiple es el tipo de herencia que permite a una clasetener más de una superclase y heredar características de sus

ancestros [Rumbaugh et al., 1991]

“La herencia múltiple es como un paracaídas: no siempre se necesita, pero cuando así ocurre, uno está verdaderamente feliz de tenerlo a mano”

[Booch, 1994]

36




71



Problemas de la herencia múltiple

Colisiones de nombresde diferentes superclases Herencia repetida

char *nombre...

Profesor

char *nombre...

Alumno

char*Profesor::nombre;

char*Alumno::nombre;

Becario

Persona

Profesor Estudiante

Becario

3.2 Herencia múltiple (ii)

72



Aproximaciones para resolver las colisiones debidas a la herencia múltiple

La semántica del lenguaje podría contemplar el choque como algo incorrecto y rehusar la compilación de la clase (Eiffel)La semántica del lenguaje podría contemplar el mismo nombre introducido por varias clases como referente al mismo atributo (CLOS)La semántica del lenguaje podría permitir el desacuerdo, pero requerir que todas las referencias al nombre califiquen de forma completa la fuente de su declaración (C++)

Aproximaciones para resolver el problema de la herencia repetidaTratar la presencia de herencia repetida como incorrecta (Eiffel)Permitir la duplicación de superclases, pero requiriendo el uso de nombres plenamente calificados para referirse a los miembros de una copia específica (C++)Se pueden tratar las referencias múltiples a la misma clase como denotando a la misma clase (C++)

3.2 Herencia múltiple (iii)

37




73



3.3 Notación en UML (i)La generalización/especialización es una relación de taxonomía

entre un elemento general y otro más específico que es plenamente consistente con el primer elemento y que le añade información adicional

Se representa a través de una línea continua que une el elemento específico (subclase) con el elemento más general (superclase) en este extremo se añade un triángulo hueco que apunta a la superclaseLa existencia de subclases adicionales que no se muestran en el diagrama se representa a través de puntos suspensivosIndicación de restricciones semánticas sobre las subclases

OverlappingDisjointCompleteIncomplete

Soporte de la herencia múltiple

74



Figura

Polígono Elipse Spline ...

Figura

Polígono Elipse Spline ...

3.3 Notación en UML (ii)

38




75



3.4 Herencia en C++Especificación de acceso

Combinaciones de los accesos a las secciones de una clase

Especificador de

acceso

Desde la propia

clase Desde las clases

derivadas Desde el exterior

public

Si

Si

Si

private

Si

No

No

protected

Si

Si

No

76



Una clase base puede tener varias derivadasUna subclase sólo tiene una superclaseSistema jerárquico arborescenteSintaxis en C++class <nombre_subclase> : [<acceso>] <nombre_superclase> {

//Cuerpo de la subclase};

El acceso puede ser private, protected o publicSi se omite el acceso, por defecto es private en el caso de clases y public en el caso de las estructurasLos elementos private de la superclase son inaccesibles para la subclase, sea cual sea el accesoSi el acceso es public, todos los elementos public y protected de la superclase siguen siendo public y protected respectivamente en la subclaseSi el acceso es private, entonces todos los elementos public y protected de la superclase pasarán a ser elementos private de la subclaseSi el acceso es protected todos los miembros public y protected de la superclase se convierten en elementos protected de la subclase

3.4 Herencia en C++Herencia simple (i)

39




77



Acceso

Descripción

public

Los miembros públicos de la clase base son miembros públicos de

la clase derivada. Los miembros protegidos de la clase base son

miembros protegidos de la clase derivada. Los miembros privados

de la clase base no son accesibles para la clase derivada

private

Los miembros públicos de la clase base son miembros privados de

la clase derivada. Los miembros protegidos de la clase base son

miembros privados de la clase derivada. Los miembros privados

de la clase base no son accesibles para la clase derivada

protected

Los miembros públicos de la clase base son miembros protegidos

de la clase derivada. Los miembros protegidos de la clase base

son miembros protegidos de la clase derivada. Los miembros

privados de la clase base no son accesibles para la clase derivada

3.4 Herencia en C++Herencia simple (ii)

78



Algunas funciones miembro no se heredan de forma automática

ConstructoresDestructorFunciones amigasFunciones estáticas de la claseOperador de asignación sobrecargado

Los atributos estáticos no se heredan

3.4 Herencia en C++Herencia simple (iii)

40




79



#include <iostream.h>class Primera {protected:

int i, j;public:

Primera() {i=j=0;}Primera(int a, int b) {i=a; j=b;}void Entra_ij(int a, int b) {i=a; j=b;}void Muestra_ij (void) {cout << endl << i << " " << j << endl;}

};// Se tiene otra clase, Segunda, que es derivada de la clase Primera// Las variables i, j de Primera pasan a ser miembros protected de// Segunda, ya que el acceso es publicclass Segunda : public Primera {

int k;public:

void Entra_k(int a) {k=a;}void Muestra_k (void) {cout << endl << k << endl;}

};// Se tiene otra clase, Tercera, que es derivada de la clase Segunda// Las variables i, j de Primera pasan a ser miembros protected de// Tercera, ya que el acceso es public// Sin embargo no tiene acceso a k de Segunda, ya que esta variable es// privateclass Tercera : public Segunda {public:

void f (void) { i=j=2;}};

3.4 Herencia en C++Herencia simple (iv)

80



void main (void) {Primera P(1,2);Segunda S;Tercera T;

S.Entra_ij(3,4);S.Entra_k(5);

P.Muestra_ij(); // Saca 1 2S.Muestra_ij(); // Saca 3 4S.Muestra_k(); // Saca 5

T.f();T.Muestra_ij(); // Saca 2 2// Los métodos de T no pueden acceder a k// Pero los métodos heredados de S síT.Entra_k(3); // Se inicia a 3 kT.Muestra_k(); // Saca 3S.Muestra_k(); // Saca 5

T.Entra_ij(5,6);T.Muestra_ij(); // Saca 5 6P.Muestra_ij(); // Saca 1 2

}

3.4 Herencia en C++Herencia simple (v)

41




81




int i, j;public:

Primera() {i=j=0;}Primera(int a, int b) {i=a; j=b;}void Entra_ij(int a, int b) {i=a; j=b;}void Muestra_ij (void) {cout << endl << i << " " << j << endl;}

};// Se tiene otra clase, Segunda, que es derivada de la clase Primera// Las variables i, j de Primera pasan a ser miembros private de// Segunda, ya que el acceso es privateclass Segunda : private Primera {

int k;public:

void Entra_k(int a) {k=a;}void Muestra_k (void) {cout << endl << k << endl;}

};// Se tiene otra clase, Tercera, que es derivada de la clase Segunda// Las variables i, j de Primera no pueden ser heredados por Tercera// ya que en Segunda son privadosclass Tercera : public Segunda {public:

void f (void) {// i=j=2; // Esto ya no es posible

}};

3.4 Herencia en C++Herencia simple (vi)

82



void main (void) {Primera P(1,2);Segunda S;Tercera T;// S.Entra_ij(3,4); // La función Entra_ij es un miembro pasa a ser

// un miembro privado de Segunda, y ya no se puede// llamar directamente

S.Entra_k(5);

P.Muestra_ij(); // Saca 1 2// S.Muestra_ij(); // Lo mismo ocurre con la función Muestra_ijS.Muestra_k(); // Saca 5T.f();// T.Muestra_ij(); // Esta función no es accesible desde TT.Entra_k(3); T.Muestra_k(); // Saca 3S.Muestra_k(); // Saca 5

}

3.4 Herencia en C++Herencia simple (vii)

42




83



Modificaciones en el ejemplo anteriorclass Segunda : private Primera {

int k;

public:

void Entra_k(int a) {k=a;}

void Muestra_k (void) {cout << k << endl;}

void da_acceso(int h, int i) {

Entra_ij(h, i);

Muestra_ij();

}

};

class Tercera : public Segunda {

public:

void f (void) {

// i=j=2; // Esto ya no es posible

da_acceso(-1,-1);

}

};void main (void) {

Tercera T;

T.f(); // Saca -1 -1

}

3.4 Herencia en C++Herencia simple (viii)

84



Los constructores y destructores no son heredados por las clases derivadasUna instancia de una clase derivada contendrá todos los miembros de la superclase, y éstos deben ser iniciadosEl constructor de la clase base debe ser llamado por el constructor de la clase derivadaEl constructor de la clase derivada debe especificar una forma de inicio para la superclaseSe usa una sintaxis similar a la empleada por los miembros de inicio para los objetos miembro de una clase

Se coloca ‘:’ después de la lista de argumentos del constructor de la clase derivada, y seguidamente el nombre de la clase base y la lista de argumentos

3.4 Herencia en C++Constructores y destructores (i)

43




85



#include <iostream.h>class B {

int a, b, c;public:

B(){a=b=c=0;}B( int a1, int a2, int a3 ) {

a=a1; b=a2; c=a3;}void DarValores( int a1, int a2, int a3 ) {

a=a1; b=a2; c=a3;}void MostrarEnteros (void) {

cout << "\n" << a << " " << b << " " << c;}

};class C : public B {

float x, y;public:

C():B(0,0,0) {x=y=0.0;}C(float a1, float a2, int a3, int a4, int a5) : B(a3, a4, a5) {x=a1; y=a2;}void MostrarFloat(void) {cout << "\n" << x << " " << y;}

};void main() {

C b, c(1, 2, 3, 4, 5);b.MostrarEnteros();b.MostrarFloat();c.MostrarEnteros();c.MostrarFloat();

}

3.4 Herencia en C++Constructores y destructores (ii)

86



En primer lugar se ejecuta el constructor de la clase baseDespués el constructor de la clase derivadaSi la clase derivada tuviera objetos miembro, sus constructores se ejecutarían después del constructor de la clase base, pero antes del constructor de la clase derivadaLos destructores se llaman en orden inverso de la derivación, es decir, de la clase derivada a la clase base

La última clase creada es la que destruye en primer lugar

3.4 Herencia en C++Constructores y destructores (iii)

44




87




class A {unsigned y;

public:A ( unsigned a1 ) : y(a1) {}~A() { cout << "\nDestructor de A\n";}void saca_y (void) {cout << y;}

};class B {

char *s;public:

B ( char *msg ) {s = new char [strlen (msg) + 1];strcpy ( s, msg );

}~B() {

delete [] s;cout << "\nDestructor de B\n";

}void msg (void ) { cout << "\n" << s;}

};

3.4 Herencia en C++Constructores y destructores (iv)

88



class C {protected:

int a, b, c;A a1;

public:C():a1(0){a=b=c=0;}C( int a1, int a2, int a3, unsigned a4 ) : a1(a4) {a=a1; b=a2; c=a3;}~C() { cout << "\nDestructor de C\n";}void DarValores( int a1, int a2, int a3 ) {a=a1; b=a2; c=a3;}void MostrarEnteros (void) {

cout << "\n" << a << " " << b << " " << c << " " ;a1.saca_y();

}};class D : public C {

float x, y;B b1;

public:D():C(0,0,0,0),b1("") {x=y=0.0;}D(float a1, float a2, int a3, int a4, int a5, unsigned a6, char *m) :

C(a3, a4, a5, a6), b1(m) {x=a1; y=a2;}~D() { cout << "\nDestructor de D\n";}void MostrarFloat(void) {

cout << "\n" << x << " " << y;b1.msg();

}};

3.4 Herencia en C++Constructores y destructores (v)

void main() {D d1, d2(1, 2, 3, 4, 5, 6, "Hola");

d1.MostrarEnteros();d1.MostrarFloat();

d2.MostrarEnteros();d2.MostrarFloat();

}

45




89



Clase derivada es un superconjunto de la clase baseUna instancia de la clase derivada puede asignarse a una instancia de la clase baseEl caso contrario no es cierto, ya que las instancias de la clase base no tienen todos los miembros de la clase derivada

3.4 Herencia en C++Conversiones (i)

90




int i, j;public:

Primera() {i=j=0;}Primera(int a, int b) {i=a; j=b;}void Entra_ij(int a, int b) {i=a; j=b;}void Muestra_ij (void) {cout << "\n" << i << " " << j;}

};class Segunda : public Primera {

int k;public:

void Entra_k(int a) {k=a;}void Muestra_k (void) {cout << " " << k;}


Primera P(1,2);Segunda S;S.Entra_ij(3,4);S.Entra_k(5);P.Muestra_ij(); // Saca 1 2S.Muestra_ij(); // Saca 3 4S.Muestra_k(); // Saca 5P=S;P.Muestra_ij(); // Saca 3 4

}

3.4 Herencia en C++Conversiones (ii)

46




91



Empleado

EmpleadoHoras Gerente

Vendedor

3.4 Herencia en C++Conversiones (iii)

92




class Empleado {protected:

char *nombre;public:

Empleado();Empleado(char *nom);~Empleado();char *Nombre() const;

};class aHoras : public Empleado {protected:

float horas;float salario;

public:aHoras ( char *nom );void FijaSalario ( float s );void FijaHoras ( float h );void SacaNombre (void) const;

};

class Gerente : public Empleado {float salario_semanal;

public:Gerente ( char *nom );void FijaSalario (float s);

};class Vendedor : public aHoras {

float comision;float ventas;

public:Vendedor (char *nom );void FijaComision ( float c );void FijaVentas ( float v );

};

3.4 Herencia en C++Conversiones (iv)

47




93



// Funciones miembro de la clase EmpleadoEmpleado::Empleado () {

nombre=0;}Empleado::Empleado( char *nom) {

nombre = new char[strlen(nom)+1];strcpy (nombre, nom);

}char *Empleado::Nombre() const {

return nombre;}Empleado::~Empleado() {

delete [] nombre;}// Funciones miembro de la clase aHorasaHoras::aHoras ( char *nom ):Empleado (nom) {

horas=0.0; salario=0.0;}void aHoras::FijaSalario ( float s ) {

salario=s;}void aHoras::FijaHoras ( float h ) {

horas=h;}void aHoras::SacaNombre (void) const {

cout <<"El nombre del trabajador es: "<< nombre << endl;}

3.4 Herencia en C++Conversiones (v)

// Funciones miembro de la clase GerenteGerente::Gerente ( char *nom ):Empleado (nom) {

salario_semanal=0.0;}void Gerente::FijaSalario (float s) {

salario_semanal=s;}// Funciones miembro de la clase VendedorVendedor::Vendedor (char *nom ):aHoras(nom) {

comision=0.0;ventas=0.0;

}void Vendedor::FijaComision ( float c ) {

comision=c;}void Vendedor::FijaVentas ( float v ) {

ventas=v;}void main (void) {

Empleado *ptr_emp;aHoras a1("Juan Palomo");Gerente g1("Alberto Lamas");Vendedor v1("Ana Vicente");ptr_emp=&a1;cout << ptr_emp->Nombre() << endl;ptr_emp=&g1;cout << ptr_emp->Nombre() << endl;ptr_emp=&v1;cout << ptr_emp->Nombre() << endl;

}

94



void main (void) {Vendedor v1("Ana Vicente"), *v2_ptr;aHoras *a1_ptr;

v2_ptr=&v1;a1_ptr=&v1;

a1_ptr->FijaHoras(40.0); // Se llama a aHoras::FijaHorasv2_ptr->FijaSalario(6.0); // Se llama a aHoras::FijaSalario// a1_ptr->FijaVentas(1000.0); // Error: no existe aHoras::FijaVentasv2_ptr->FijaVentas(1000.0); // Se llama a Vendedor::FijaVentas

}

3.4 Herencia en C++Conversiones (vi)

void main (void) {aHoras a1("Pepe Pérez");Empleado *ptr = &a1;Vendedor *v1;

v1=(Vendedor *) ptr; // Lícito pero incorrectocout << "\n" << v1->Nombre(); // Saca Pepe Pérez

// v1->FijaComision(1.5); // La clase aHoras no tiene el// miembro FijaComision

// v1->SacaComision(); // Error}

48




95



Existen tres conversiones estándar principales entre una clase derivada y una clase base

Un objeto de una clase derivada se convierte de forma implícita en objetos de clases base públicasUna referencia a una clase derivada se convierte implícitamente en una referencia a una clase base públicaUn puntero a una clase derivada se convierte implícitamente en una referencia a una clase base pública

3.4 Herencia en C++Conversiones (vii)

96



Una clase derivada puede tener un miembro con el mismo nombre que un miembro de la clase baseEn estos casos cuando se referencia el miembro duplicado, el compilador asumirá que se desea acceder al miembro de la clase derivadaEsto se conoce como anulación (overriding) del miembro de la clase basePara acceder al miembro de la clase base se debe utilizar el operador de resolución de ámbito

3.4 Herencia en C++Ambigüedades en la herencia simple (i)

49




97



#include <iostream.h>class Base {protected:

int j;public:

Base (int x):j(x){}

void Calcula (void) {cout << j*j << endl;

}};class Derivada : public Base {

int j;public:

Derivada (int y, int z) : j(y), Base(z) {}void Calcula (void) {

cout << j*Base::j << endl;}

};void main() {

Derivada d(4,8);d.Calcula(); // Saca 32d.Base::Calcula(); // Saca 64

}

3.4 Herencia en C++Ambigüedades en la herencia simple (ii)

98



Una subclase puede tener más de una superclase

Sintaxisclass <nombre_subclase> : <lista_herencia> {

// Cuerpo de la clase};

La lista de herencia consta de los nombres de las superclases separadas por comas

La herencia está gobernada por los mecanismos de acceso private, public y protectedEl orden en que se especifican las clases bases en la lista de herencia sólo afecta al orden en el que se invocan los constructores y destructores de las clases base desde los constructores y destructores de la clase derivada

3.4 Herencia en C++Herencia múltiple (i)

50




99



#include <iostream.h>class Base1 {protected:

int b1;public:

void Inicia_B1(int v) { b1=v; }};class Base2 {protected:

int b2;public:

void Inicia_B2(int v) { b2=v; }int Ret (void) { return b2; }

};class Der: public Base1, public Base2 {public:

void print (void) { cout << "\nb1 = " << b1 << "\tb2 = " << Ret(); }};void main (void) {

Der d;d.Inicia_B2(78);d.Inicia_B1(34);d.print(); // Saca 34 y 78

}

3.4 Herencia en C++Herencia múltiple (ii)

100



#include <iostream.h>class A {protected:

int a;public:

A (int valor) {cout << "\nConstructor de A";a=valor;

}~A () { cout << "\nDestructor de A"; }

};class B {protected:

int b;public:

B (int valor) {cout << "\nConstructor de B";b=valor;

}~B () { cout << "\nDestructor de B"; }

};class C : public A, public B {public:

C(int v1, int v2) : B(v2), A(v1) {cout << "\nConstructor de C";

}~C () { cout << "\nDestructor de C"; }int operar (void) { return a*a+b*b; }


C obj(4, 5);cout << "\n" << obj.operar();

};

Constructor de AConstructor de BConstructor de C41Destructor de CDestructor de BDestructor de A

3.4 Herencia en C++Herencia múltiple (iii)

51




101



La herencia múltiple permite al diseñador de la jerarquía de herencia situar los datos donde sea necesarioEjemplo: Dada la siguiente jerarquía de herencia, se quiere incluir una clase X de la cual hereden las clases E y F

A

C D

E F

3.4 Herencia en C++Herencia múltiple (iv)

102



Solución con herencia simple

X

C D

E F

A

3.4 Herencia en C++Herencia múltiple (v)

Solución con herencia múltiple

A

C D

E F

X

52




103



#include <iostream.h>class Base1 {protected:

int b1;public:

void Inicia(int v) { b1=v; }};class Base2 {protected:

int b2;public:

void Inicia(int v) { b2=v; }int Ret (void) { return b2; }

};class Der: public Base1, public Base2 {public:

void print (void) { cout << "\nb1 = " << b1 << "\tb2 = " << Ret(); }};

void main (void) {// Error de compilaciónDer d;d.Inicia(78);d.Inicia(34);d.print();

}

3.4 Herencia en C++Ambigüedades en la herencia múltiple (i)

Solución:void main (void) {

Der d;d.Base1::Inicia(78);d.Base2::Inicia(34);d.print // Saca 78 y 34

}

104



En una lista de herencia una clase base sólo puede aparecer una sola vezDe forma indirecta una clase base puede aparecer varias vecesLa ambigüedad se produce cuando se hereda de dos o más clases base, que de forma directa o indirecta heredan de la misma clase

A B

C

Clases Basedirectas

B C

D

A

Clases Basedirectas

Clase Baseindirecta

A

B C

D

Clases Basedirectas

Clase Baseindirecta

Ambigüedad

3.4 Herencia en C++Ambigüedades en la herencia múltiple (ii)

53




105



#include <iostream.h>class A {protected:

int i;};class B : public A {};class C : public A {};class D : public B, public C {public:

int Retorna (void) { return i;}};void main (void) {

D d1;cout << d1.Retorna();

}Return C::i;

3.4 Herencia en C++Ambigüedades en la herencia múltiple (iii)

Ambigüedad

Solución

106



Empleado

EmpleadoHoras Gerente

Vendedor

GerenteVentas

class GerenteVentas: public Vendedor, public Gerente {public:

GerenteVentas(char *nom);};

3.4 Herencia en C++Ambigüedades en la herencia múltiple (iv)

54




107



void main(void) {GerenteVentas gv("Marcelino Ostroski");cout << "\n" << gv.Nombre(); // Error

}

void main(void) {GerenteVentas gv("Marcelino Ostroski");cout << "\n" << gv.Gerente::Nombre();// Esto sería equivalente// cout << "\n" << gv.Vendedor::Nombre();

}

3.4 Herencia en C++Ambigüedades en la herencia múltiple (v)

108



void main(void) {Empleado *ptr_emp;GerenteVentas *ptr_gv, gv("Pepe");ptr_gv=&gv;ptr_emp=ptr_gv;cout << "\n" << ptr_emp->Nombre();

}

void main(void) {Empleado *ptr_emp;GerenteVentas *ptr_gv, gv("Pepe");ptr_gv=&gv;ptr_emp=(Gerente *)ptr_gv;cout << "\n" << ptr_emp->Nombre();

}

3.4 Herencia en C++Ambigüedades en la herencia múltiple (vi)

55




109



#include <iostream.h>class A {public:

int v1;};class B : virtual public A {public:

float v2;};class C : virtual public A {public:

float v3;};class D : public B, public C {public:

char v4;};void main() {

D o;o.v4='a';o.v3=3.14;o.v2=1.7;o.v1=9;cout << "\n" << o.v1 << " " << o.v2 << " " << o.v3 << " " << o.v4;

}

3.4 Herencia en C++Ambigüedades en la herencia múltiple (vii)

110



El orden de la llamada a los constructores puede producir confusión, debido a que C++ sigue el siguiente orden de iniciación

Todas las clases virtuales se inician primero, es decir, sus constructores se ejecutan en primer lugar

El constructor de cada clase virtual se llama una sola vezSi existen varias clases virtuales, sus constructores se ejecutan en el orden en que han sido declarados

Las clases base no virtuales se inician en el orden que aparecen en la declaración de clasesPor último, se ejecuta el constructor de la clase derivada

Los destructores se invocan de forma inversa a los constructores

3.4 Herencia en C++Ambigüedades en la herencia múltiple (viii)

56




111



#include <iostream.h>#include <string.h>class Empleado {protected:

char *nombre;public:

Empleado();Empleado (char *nom);char *Nombre() const;~Empleado();

};class aHoras : virtual public Empleado {protected:

float horas;float salario;

public:aHoras ( char *nom );void FijaSalario ( float s );void FijaHoras ( float h );void SacaNombre (void) const;

};

class Gerente : virtual public Empleado {float salario_semanal;

public:Gerente ( char *nom );void FijaSalario (float s);

};class Vendedor : public aHoras {

float comision;float ventas;

public:Vendedor (char *nom);void FijaComision (float c);void FijaVentas (float v);void SacaComision (void);

};class GerenteVentas : public Vendedor, public Gerente {public:

GerenteVentas (char *nom);};

3.4 Herencia en C++Ambigüedades en la herencia múltiple (ix)

112



// Funciones miembro de la clase EmpleadoEmpleado::Empleado () {

nombre = 0;cout << "Constructor por defecto de Empleado" << endl;

}Empleado::Empleado (char * nom) {

nombre = new char[strlen(nom)];strcpy (nombre, nom);cout << "Constructor de Empleado" << endl;

}Empleado::~Empleado(){

delete [] nombre;cout << "Destructor de Empleado" << endl;

}char *Empleado::Nombre() const {

return nombre;}// Funciones miembro de la clase aHorasaHoras::aHoras ( char *nom ):Empleado (nom) {

horas=0.0; salario=0.0;cout << "Constructor aHoras" << endl;

}

3.4 Herencia en C++Ambigüedades en la herencia múltiple (x)

57




113



void aHoras::FijaSalario ( float s ) {salario=s;}void aHoras::FijaHoras ( float h ){horas=h;}void aHoras::SacaNombre (void) const {

cout << "\nEl nombre del trabajador es: " << nombre;}// Funciones miembro de la clase GerenteGerente::Gerente ( char *nom ):Empleado (nom){

salario_semanal=0.0;cout << "Constructor de Gerente" << endl;

}void Gerente::FijaSalario (float s) {salario_semanal=s;}// Funciones miembro de la clase VendedorVendedor::Vendedor (char *nom ):aHoras(nom) {

comision=0.0; ventas=0.0;cout << "Constructor de Vendedor" << endl;

}void Vendedor::FijaComision ( float c ) {comision=c;}void Vendedor::FijaVentas ( float v ) {ventas=v;}void Vendedor::SacaComision (void) {cout << "\n" << comision;}// Funciones miembro de la clase GerenteVentasGerenteVentas::GerenteVentas(char *nom):Vendedor(nom),Gerente(nom),

Empleado(nom){cout << "Constructor de GerenteVentas" << endl;

}void main (void) {

GerenteVentas *p_gv, gv1("Pepe");Empleado *p_emp;p_gv=&gv1; p_emp=p_gv;cout << p_emp->Nombre() << endl;

}

3.4 Herencia en C++Ambigüedades en la herencia múltiple (xi)

114



En una jerarquía de herencia la regla de dominio se emplea para resolver ambigüedadesSi una clase base y una clase derivada tienen un miembro con el mismo nombre, el que esté en la clase derivada es el dominante

3.4 Herencia en C++Regla de dominio (i)

A

B

C

void A::func()

void B::func()

58




115



A

B C

D

class A {...};class B: virtual public A {...};class C: virtual public A {...};class D: public B, pulic C {...};

3.4 Herencia en C++Regla de dominio (ii)

A

B

D


class A {public:

float func() { return 3.1416;}};class B : virtual public A {public:

float func() { return 2.778;}};class C : virtual public A, public B {};

void main (void) {C c1;cout << c1.func() << endl;// Se llama a B::func()

}

116



A

B C

D

#include <iostream.h>class A {public:

float func() { return 3.1416;}};class C {public:

float func() { return 2.778;}};class B : virtual public A {};class D : public B, public C {};

void main (void) {D d1;

cout << d1.func() << endl; // Error}

3.4 Herencia en C++Regla de dominio (iii)

59




117



3.5 Herencia en Java (i)La herencia consiste en la capacidad de extender el comportamiento de una clase, creando subclasesCuando se extiende una clase para crear otra, la nueva hereda los atributos y métodos de la extendidaLa clase en la que se basa la extensión se denomina superclaseJava no permite herencia múltiplePara indicar que una clase es descendiente de otra se utiliza lapalabra reservada extendsUna referencia puede referenciar a las instancias de una clase ylas instancias de todas sus clases descendientes

118



class nombre_de_clase extends nombre_superclase {tipo variable_de_instancia1;tipo variable_de_instancia2;...tipo variable_de_instanciaN;

tipo nombre_de_método1 (lista_de_parámetros) {cuerpo_del_método;

}tipo nombre_de_método2 (lista_de_parámetros) {

cuerpo_del_método;}...tipo nombre_de_métodoN (lista_de_parámetros) {

cuerpo_del_método;}

}

Plantilla Básica de una Clase Java

3.5 Herencia en Java (ii)

60




119



Ejemplo de herencia en Java

class Punto {public int x, y;public Punto (int x, int y) {

this.x=x;this.y=y;

}public Punto() {

this(0,0);}public int CoordenadaX() {

return x;}public int CoordenadaY() {

return y;}

}

class Punto3D extends Punto{public int z;public Punto3D(int x, int y, int z) {

this.x=x;this.y=y;this.z=z;

}public Punto3D () {

this (0,0,0);}public int CoordenadaZ () {

return z;}

}

3.5 Herencia en Java (iii)

120



Ejemplo de herencia en Java (cont.)class Main {

static public void main (String args[]) {Punto3D p1 = new Punto3D();Punto3D p2 = new Punto3D(1,2,3);

System.out.println("Coordenada X de p1 " + p1.CoordenadaX());System.out.println("Coordenada Y de p1 " + p1.CoordenadaY());System.out.println("Coordenada Z de p1 " + p1.CoordenadaZ());


}}

Coordenada X de p1 0Coordenada Y de p1 0Coordenada Z de p1 0Coordenada X de p2 1Coordenada Y de p2 2Coordenada Z de p2 3

3.5 Herencia en Java (iv)

61




121



Comentarios al primer ejemplo de herenciaLa clase Punto y Punto3D declaran públicos sus atributos, es un error que rompe el encapsulamiento de las clasesSi los atributos de la clase Punto se declarasen privados, no serían accesibles desde la subclase

Ejercicio: comprobar qué sucedería si en el ejemplo anterior sólo se cambia private por public en la declaración de los atributos de la clase Punto

Si los atributos de la clase Punto se declarasen protegidos, serían accesibles desde la subclase, pero también desde cualquier otra parte del código del paquete Los constructores de Punto3D repiten código ya existente en la superclase

3.5 Herencia en Java (v)

122



Uso de protected en el ejemplo anterior

class Punto {protected int x, y;public Punto (int x, int y) {

this.x=x;this.y=y;

}public Punto() {



return y;}

}

class Punto3D extends Punto{private int z;public Punto3D(int x, int y, int z) {

this.x=x;this.y=y;this.z=z;



return z;}

}

3.5 Herencia en Java (vi)

62




123



Uso de protected en el ejemplo anterior (cont.)class Main {

static public void main (String args[]) {Punto3D p1 = new Punto3D();Punto3D p2 = new Punto3D(1,2,3);p1.x=1;p2.x=10;/* p2.z=9;*/System.out.println("Coordenada X de p1 " + p1.CoordenadaX());System.out.println("Coordenada Y de p1 " + p1.CoordenadaY());System.out.println("Coordenada Z de p1 " + p1.CoordenadaZ());


}}

Coordenada X de p1 1Coordenada Y de p1 0Coordenada Z de p1 0Coordenada X de p2 10Coordenada Y de p2 2Coordenada Z de p2 3

3.5 Herencia en Java (vii)

124



class Punto {private int x, y;public Punto (int x, int y) {

this.x=x;this.y=y;

}public Punto() {



return y;}

}

class Punto3D extends Punto{private int z;public Punto3D(int x, int y, int z)

super(x, y);this.z=z;



return z;}

}

Nueva versión del ejemplo

3.5 Herencia en Java (viii)

63




125



class Main {static public void main (String args[]) {

Punto3D p1 = new Punto3D();Punto3D p2 = new Punto3D(1,2,3);/* p1.x=1;

p2.x=10;p2.z=9; */



}} Coordenada X de p1 0

Coordenada Y de p1 0Coordenada Z de p1 0Coordenada X de p2 1Coordenada Y de p2 2Coordenada Z de p2 3

Nueva versión del ejemplo (cont.)

3.5 Herencia en Java (ix)

126



Construcción super( )Cuando se extiende una clase, la nueva clase debe elegir uno de los constructores de su superclase para invocarloEn un constructor de la subclase se puede invocar directamente uno de los constructores de la superclase usando la forma de invocación explícita basada en la construcción super( )

Si no se invoca un constructor de la superclase como primera sentencia ejecutable del nuevo constructor, es invocado automáticamente el constructor sin argumentos de la superclase antes de que se ejecute ninguna sentencia del nuevo constructorSi la superclase no tiene un constructor no-arg hay que invocar explícitamente el constructor de la superclase con los parámetros oportunosSi se usa super(), debe ser la primera sentencia del nuevo constructor

La referencia super() también se puede utilizar para seleccionar directamente métodos con nombre

3.5 Herencia en Java (x)

64




127



Dependencias del orden del constructorCuando se crea un objeto a todos sus atributos se les asignan valores iniciales por defecto para sus tipos respectivos, y a continuación se invoca al constructorCada constructor tiene tres fases

Invocar un constructor de la superclaseIniciar los atributos utilizando sus sentencias de iniciaciónEjecutar el cuerpo del constructor

3.5 Herencia en Java (xi)

128



3.6 Clasificación de la Herencia

De acuerdo al grado de libertad para redefinir el cuerpo de los métodos heredados [Ancona et al., 1992]

Herencia minimal, herencia regular y herencia conservadora

En [Halbert y O’Brien, 1987] se habla deHerencia de implementaciones completas y herencia de implementaciones parciales

Bertrand Meyer (1997) define doce usos válidos de herencia agrupados en tres familias

Herencia de modelo, herencia de variación y herencia de software

65




129



Familias Principales de Herencia

Herencia de modeladoRefleja relaciones “es un” entre las abstracciones de un modelo

Herencia softwareExpresa relaciones software, que no son obvias en el modelo

Herencia con variaciónSirve para describir una clase mediante sus diferencias con otras clases

3.6.1 Clasificación de Meyer (i)

130



Usos válidos de la herencia

Herencia convariación

Herencia software

Herencia desubtipo

Herencia devista

Herencia deextensión

Herencia derestricción

Herencia demodelado

Herencia porvariación funcional

Herencia porvariación de tipo

Herencia deconversión a diferida

Herencia dematerialización

Herencia deestructura

Herencia de implementación

Herencia defacilidades

Herencia deconstantes

Herencia deMáquina

[Meyer, 1997]

3.6.1 Clasificación de Meyer (ii)

66




131



3.7 Uso adecuado de la herencia (i)Regla de herencia “es un”

La clase B no debe heredar de la clase A, a no ser que se pueda argumentar de alguna forma que se puede ver toda instancia de laclase B también como una instancia de la clase ARelajación en la herencia de implementación

Persona Coche

PropietarioCoche

¡¡¡ Mal diseño !!!

Persona

PropietarioCoche Coche

Diseño correcto

132



Selección entre herencia o relaciones de tipo cliente o agregación [Meyer, 1997]

Al decidir la forma de expresar la dependencia de una clase B con respecto a otra clase A, se aplican los siguientes criterios

Si toda instancia de B posee inicialmente un componente del tipo A, pero ese componente puede tener necesidad de ser sustituido durante la ejecución por un objeto de tipo diferente, hacer que B sea cliente de ASi hay necesidad de que las entidades del tipo A denoten objetos de tipo B, o de que hay estructuras polimorfas que contengan objetos de tipo A de las cuales algunas pueden ser de tipo B, hacer que B herede de A

3.7 Uso adecuado de la herencia (ii)

67




133



4. Polimorfismo

134



4.1 IntroducciónPosibilidad de utilizar el mismo símbolo con fines distintos cuando el contexto está claroUn solo nombre (como puede ser la declaración de una variable) puede denotar objetos de muchas clases diferentes que se relacionan por alguna superclase comúnFaceta más interesante del polimorfismo cuando interactúan las características de la herencia y el enlace dinámico

Universal Ad-hoc

Paramétrico Inclusión Sobrecarga Coherción

Polimorfismo

68




135



“Toma de varias formas; propiedad que permite a una operación tener distintos comportamientos en diferentes clases” [Rumbaugh et al., 1991]“La posibilidad de que una variable o una función adopte diferentes formas en tiempo de ejecución o, más específicamente, a la posibilidad de referirse a instancias de varias clases” [Graham, 1994]“Concepto de la teoría de tipos, de acuerdo con el que un nombre (como una declaración de una variable) puede denotar objetos de muchas clases diferentes que se relacionan mediante alguna superclase común; así todo objeto denotado por este nombre es capaz de responder a algún conjunto común de operaciones de diferentes modos” [Booch, 1994]“Capacidad de una entidad consistente en poder conectarse a objetos de varios tipos” [Meyer, 1997]

Durante la ejecución debiera ser posible conectar entidades (nombres en los textos de software que representan objetos durante la ejecución) a objetos de distintos tipos posibles, bajo el control del sistema de tipos basado en la herencia

4.2 Definición

136



4.2 Polimorfismo en C++Introducción

En C++ se tiene un polimorfismo ad-hoc conLa sobrecarga de funcionesLa sobrecarga de operadores

En C++ se consigue el polimorfismo por inclusión conLas funciones virtuales

69




137



Una función virtual es una función miembro que se declara como tal en la clase base y se redefine en una o más clases derivadasPor defecto las funciones de C++ tienen ligadura estática, pero cuando se definen como virtuales tienen ligadura dinámicaLas funciones virtuales se enlazan dinámicamente en tiempo de ejecuciónCuando se llama a una función virtual utilizando un puntero a la clase base, que apunta a una clase derivada, la versión de la función existente en la clase derivada es la que se ejecutaPor tanto, cuando se apunta a diferentes objetos, se ejecutan versiones diferentes de la función que se ha definido como virtualSintaxis

virtual <tipo> <nombre_función> (<lista_argumentos>)La palabra virtual no es necesario repetirla en la declaración de la función en las clases derivadas, aunque no es un error el hacerloSe puede usar una función virtual aunque no se derive ninguna clase de su clase, y no es necesario que una clase derivada que no necesite su propia versión de una función virtual proporcione una

4.2 Polimorfismo en C++Funciones virtuales (i)

138




class Prueba {public:

virtual void mensaje (void) {cout << "\nEsta es la función de la clase base.\n";

}};class Der1 : public Prueba {public:

void mensaje (void) {cout << "\nEsta función es de la clase Der1\n";


virtual void mensaje (void) {cout << "\nEsta es la función de la clase Der2\n";

}};

4.2 Polimorfismo en C++Funciones virtuales (ii)

void main (void) {Prueba p, // Objeto de la clase Prueba

*ptr_p; // Puntero a un objeto de la clase PruebaDer1 d1; // Objeto de la clase Der1Der2 d2; // Objeto de la clase Der2ptr_p=&p;ptr_p->mensaje(); // Se está utilizando la función de la clase baseptr_p=&d1;ptr_p->mensaje(); // Se está utilizando la función de la clase Der1ptr_p=&d2;ptr_p->mensaje(); // Se está utilizando la función de la clase Der2

}

70




139



Notas de interés sobre el programa anteriorEn C++, las funciones virtuales siguen la siguiente premisa: la función debe ser declarada como virtual en la primera clase en que esté presente, siguiendo el orden de derivación. Esta regla tiene como consecuencia inmediata que normalmente las funciones virtuales se declaran en la clase de mayor nivel de la jerarquíaEn la clase Prueba se ha declarado la función mensaje como una función virtual, siguiendo la norma anterior. Con lo que su redefinición en las clases derivadas es lícitaLa redefinición de la función mensaje se da en Der1 y en Der2Cuando se redefine la función mensaje en la clase Der2 se ha utilizado la palabra reservada virtual, aunque no hace falta. Es una forma de ilustrar que esto, aunque innecesario, no es causa de errorCuando se hace que ptr_p apunte a p, y a continuación se llama a la función mensaje, y dado que mensaje es una función virtual, el compilador determina en momento de ejecución cual es la función mensaje a la que se está accediendo mediante el tipo del objeto al que apunta ptr_p. Como en este caso se trata de una instancia de la clase Prueba, se ejecuta la función mensaje que se encuentra definida en la dicha claseCuando ptr_p apunte a los objetos d1 y d2 se ejecutarán las versiones de la función mensaje que se encuentran definidas en las clases Der1 y Der2 respectivamente

4.2 Polimorfismo en C++Funciones virtuales (iii)

140



Para conseguir el polimorfismo en tiempo de ejecución mediante funciones virtuales se debe acceder a dichas funciones mediante un puntero declarado como puntero a la clase baseLas funciones virtuales pueden utilizarse con la sintaxis habitual, pero de esta forma no se estaría logrando el polimorfismo en tiempo de ejecuciónRestricciones de uso

Los prototipos de las funciones deben ser los mismosTodas retornan el mismo tipoDeben ser funciones miembroNo pueden ser estáticasLos destructores pueden ser virtuales, los constructores no

4.2 Polimorfismo en C++Funciones virtuales (iv)

71




141



class Base{

public:

virtual int vf();

};

class Derivada: public Base{

public:

virtual int vf();

};

class Base{

public:

virtual int vf();

};

class Derivada: public Base{

public:

virtual int vf();

};

void prueba(Base* bp){

bp->vf();

}

.........

Derivada d;

prueba(&d);


bp->vf();

}

.........

Derivada d;

prueba(&d);

bp es un puntero a Base pero debido a la ligadura dinámica en este llamada se invocará al métodovf() de Derivada

4.2 Polimorfismo en C++Funciones virtuales (v)

142



Ligadura estLigadura estáática tica vsvs ligadura dinligadura dináámicamica–– Ligadura estLigadura estááticatica: El compilador utiliza el tipo del puntero para hacer el enlace a la función en tiempo de

compilación–– Ligadura dinLigadura dináámicamica: La decisión sobre qué función llamar es hecha en tiempo de ejecución y depende de la

clase del objeto apuntado (no del tipo del puntero)

Código de vf() de la clase Base

Código de vf() de la clase Derivada

Segmento de códigovptr

Base

vptr

Derivada

Tabla Virtual de Base

vf()

.......

Tabla Virtual de Derivada

vf()

.......


bp->vf();

}


bp->vf();

}

call &(vf() de Base)call &(vf() de Base)

Binding Estático para vf()

call bp->pvtr[índice de vf()]call bp->pvtr[índice de vf()]

Binding Dinámico para vf()

4.2 Polimorfismo en C++Funciones virtuales (vi)

72




143



#include <iostream.h>class Prueba {public:


}virtual void mensaje (char *s) {

cout << "\nBASE: " << s << "\n";}

};class Der1 : public Prueba {public:


}void mensaje (char *s) {

cout << "\nDER1: " << s << "\n";}

};class Der2 : public Prueba {public:

virtual void mensaje (void);// Pierde su condición de virtualvoid mensaje (char *s, int a) {

cout << "\nDER2: " << s << " "<< a << "\n";}

};// La palabra virtual no es necesariavoid Der2::mensaje (void) {

cout << "\nEsta es la función de la clase Der2\n";}

4.2 Polimorfismo en C++Funciones virtuales (vii)

144




*ptr_p; // Puntero a un objeto de la clase PruebaDer1 d1; // Objeto de la clase Der1Der2 d2; // Objeto de la clase Der2

ptr_p=&p;ptr_p->mensaje(); // Se está utilizando la función de la clase baseptr_p->mensaje("Hola");

ptr_p=&d1;ptr_p->mensaje();// Se está utilizando la función de la clase Der1ptr_p->mensaje("Caracola");

ptr_p=&d2;ptr_p->mensaje();// Se está utilizando la función de la clase Der2

// ptr_p->mensaje(":))))", 5); // Error porque en la clase base// no existe una función que se// amolde a estos argumentos

}

4.2 Polimorfismo en C++Funciones virtuales (viii)

73




145



#include <iostream.h>class Prueba {public:





void mi_mensaje ( void ) {cout << "\nEsta función es de la clase Der2\n";

}};class Der3 : public Der1 {public:

void mi_mensaje ( void ) {cout << "\nEsta función es de la clase Der3\n";

}};

4.2 Polimorfismo en C++Funciones virtuales (ix)

146



4.2 Polimorfismo en C++Funciones virtuales (x)


*ptr_p; // Puntero a un objeto de la clase PruebaDer1 d1; // Objeto de la clase Der1Der2 d2; // Objeto de la clase Der2Der3 d3; // Objeto de la clase Der3ptr_p=&p;ptr_p->mensaje();// Se está utilizando la función de la clase baseptr_p=&d1;ptr_p->mensaje();// Se está utilizando la función de la clase Der1ptr_p=&d2;ptr_p->mensaje();// Se está utilizando la función de la clase baseptr_p=&d3;ptr_p->mensaje();// Se está utilizando la función de la clase Der1

}

74




147



#include <iostream.h>class Base {public:

void mensaje (void) {cout << “Estoy en la clase Base :)))" << endl;

}};class Der1 : public Base {public:

void mensaje (void) {cout << “Estoy en la clase Der1 :)))" << endl;

}};

class Der2 : public Base {public:

void mensaje (void) {cout << “Estoy en la clase Der2 :)))" << endl;

}};void main (void) {

Base *p_base;Der1 d1;Der2 d2;p_base=&d1;p_base->mensaje(); // Estoy en la clase base :)))p_base=&d2;p_base->mensaje(); // Estoy en la clase base :)))

}

4.2 Polimorfismo en C++Funciones virtuales (xi)

148



4.2 Polimorfismo en C++Funciones virtuales (xii)

&d1

&d2

p_base

p_base

p_base->mensaje()

p_base->mensaje()

mensaje()

mensaje()

mensaje()

Base

Der1

Der2

75




149



El orden de llamada de los destructores es el inverso a la llamada los constructoresCuando un objeto de la clase derivada es eliminado, el destructor de la clase derivada se llama antes que el de la clase baseCuando se destruyen objetos dinámicos con el operador delete, puede haber problemas

Si el operador delete se aplica a un puntero a la clase base, se llama al destructor de la clase base, sin tener en cuenta si dicho puntero estaba apuntando a una instancia de una clase derivadaLa solución es declarar el destructor de la clase base como virtual. Esto produce que los destructores de las clases derivadas sean virtuales aunque no compartan el mismo nombreAhora al invocar al operador delete con un puntero de la clase base se llamará al destructor adecuado

4.2 Polimorfismo en C++Destructores Virtuales

150



Es una función que se declara en la clase base, y que no tiene una definición relativa a la baseLas clases derivadas se ven forzadas a definir su propia versión, ya que no pueden usar la definida en la baseSintaxis

virtual <tipo> <nfunción>(<lista>) = 0;No son funciones vacíasUna función virtual pura no se puede ejecutar

4.2 Polimorfismo en C++Funciones Virtuales Puras

76




151



Son aquéllas que tienen alguna función virtual puraSólo se pueden utilizar como clases baseNo pueden tener instanciasSe pueden declarar punteros a clases abstractasProporcionan una interfaz en un cierto nivel de herencia

4.2 Polimorfismo en C++Clases Abstractas

152



4.2 Polimorfismo en C++Conversión descendente (downcasting) (i)

Una conversión de una clase derivada en una clase base se denomina conversión ascendente o upcasting

Es una operación habitual que promueve el principio de sustituciónUna clase derivada es un superconjunto de cualquiera de sus ancestros

Una conversión de una clase base en una clase derivada se denomina conversión descendente o downcasting

Es una operación potencialmente peligrosa

Una conversión que va de una clase base a una clase hermana se denomina conversión cruzada o crosscasting

77




153



4.2 Polimorfismo en C++Conversión descendente (downcasting) (ii)

Operador static_castEl estándar ANSI/ISO C++ introduce nuevos operadores de conversión para usar en lugar del estilo tradicionalEl operador static_cast permite la conversión entre tiposLa comprobación de tipos se realiza en tiempo de compilaciónEste operador realiza conversiones estándares y sus inversasRealizar conversiones ilegales con este operador produce erroresde sintaxis

Conversiones de tipos constantes a tipos no constantesConversiones de punteros y referencias entre tipos no relacionados por herencia públicaConversiones a un tipo para el que no existe un constructor apropiado o bien un operador de conversión

154



4.2 Polimorfismo en C++Conversión descendente (downcasting) (iii)


class Base {public:

void f () {cout << "BASE\n";}};

class Derivada: public Base {public:

void f () {cout << "DERIVADA\n";

}};

void test (Base *);

int main () {double d = 3.15;int i = static_cast <int> (d);

cout << "d = " << d;cout << "\ni = " << i << endl;

Base b;test (&b);

return 0;}

void test (Base *basPtr) {Derivada *derPtr;derPtr=static_cast<Derivada *>(basPtr);derPtr->f();

}d = 3.15i = 3DERIVADA

78




155



4.2 Polimorfismo en C++Conversión descendente (downcasting) (iv)

Operador dynamic_castSe utiliza con tipos polimórficos para asegurar que las conversiones tienen lugar en tiempo de ejecución

El tipo destino de este operador no tiene por que ser polimórfico

Se utiliza para realizar una conversión descendente de un puntero a un objeto de una clase base a un puntero a un objeto de una clase derivada en una situación polimorfaLa utilización de información de tipos en tiempo de ejecución se denomina “información de tipos en tiempo de ejecución”y se suele abreviar como RTTI (Run Time Type Identification)

156



4.2 Polimorfismo en C++Conversión descendente (downcasting) (v)

Figura

Círculo

Cilindro

ImprimeAreaFigura

79




157



4.2 Polimorfismo en C++Conversión descendente (downcasting) (vi)

#include <iostream.h>#include <math.h>

class Figura {public:

virtual double area () const=0;};

class Circulo: public Figura {public:

Circulo(double r=1.0) {radio = r;

}virtual double area () const {

return M_PI * radio * radio;}

protected:double radio;

};

class Cilindro : public Circulo {public:

Cilindro (double a = 1.0) {altura = a;

}virtual double area () const {

return 2.0 * M_PI * radio * altura + 2.0 * Circulo::area();

}private:

double altura;};

void imprimeAreaFigura( const Figura *);

158



4.2 Polimorfismo en C++Conversión descendente (downcasting) (vii)

void imprimeAreaFigura( const Figura * figPtr) {const Circulo *cirPtr;const Cilindro *cilPtr;

cilPtr = dynamic_cast <const Cilindro *> (figPtr);

if (cilPtr != 0)cout << “ÁREA DEL CILINDRO: " << cilPtr->area() << endl;

else {cirPtr = dynamic_cast <const Circulo *> (figPtr);if (cirPtr !=0)

cout << “ÁREA DEL CÍRCULO: " << cirPtr->area() << endl;else

cout << "No es ni un círculo ni un cilindro !!!" << endl;}

}

80




159



4.2 Polimorfismo en C++Conversión descendente (downcasting) (viii)

int main () {Circulo cir;Cilindro cil;Figura *figPtr=0;

imprimeAreaFigura(&cir);imprimeAreaFigura(&cil);imprimeAreaFigura(figPtr);return 0;

}

ÁREA DEL CÍRCULO: 3.14159ÁREA DEL CILINDRO: 12.5664No es ni un círculo ni un cilindro !!!

160



4.2 Polimorfismo en C++Información de tipo extendida (i)

El operador dynamic_cast sirve para la mayoría de las necesidades de información sobre el tipo de un objeto

Asegura que el código escrito que lo utiliza funciona correctamente con las clases derivadas de aquéllas explícitamente mencionadas por el programadorPreserva la flexibilidad y la extensibilidad de una forma similar a las funciones virtuales

A veces es esencial conocer el tipo exacto de un objeto

El operador typeid sirve para este propósito dando como resultado un objeto que representa el tipo de su operando

81




161



4.2 Polimorfismo en C++Información de tipo extendida (ii)

Es decir, typeid() devuelve una referencia a un tipo de la biblioteca estándar definido en <typeinfo>

Dado un nombre de tipo como operando, typeid()devuelve una referencia a un type_info() que representa el nombre del tipoDada una expresión como operando, typeid() devuelve una referencia a un type_info() que representa el tipo de objeto indicado por la expresión

El uso más común de typeid() es la búsqueda del tipo de un objeto al cual se referencia a través de un puntero o referencia

162



4.2 Polimorfismo en C++Información de tipo extendida (iii)

Si el valor de un operando puntero o referencia es 0, typeid() lanza una excepción bad_typeidNo se garantiza que exista sólo un objeto type_info para cada tipo del sistema

Se debería utilizar == sobre objetos type_info para comprobar igualdad, en lugar de hacerlo sobre punteros a dichos objetos

Algunas veces se desea conocer el tipo exacto de un objeto para realizar algún servicio estándar sobre el objeto completo (y no sólo sobre alguna base del objeto)

Idealmente, este tipo de servicios se deberían presentar como funciones virtuales para que no sea necesario conocer el tipo exacto del objetoPero en algunos casos no se puede asumir ninguna interfaz común para cada objeto manipulado, por lo que se hace necesario el desvío a través del tipo exacto

void f (Figura& r, Figura* p) {typeid(r); // Tipo de objeto referenciado por rtypeid(*p); // Tipo de objeto apuntado por ptypeid(p); // Tipo de puntero (Figura *). Poco común

}

82




163



4.2 Polimorfismo en C++Información de tipo extendida (iv)

#include <iostream.h>#include <typeinfo>

template <typename T>T maximo (T valor1, T valor2, T valor3) {

T maxx = valor1;if (valor2 > maxx) maxx = valor2;if (valor3 > maxx) maxx = valor3;const char * Tipo = typeid(T).name();cout << "Se han comparado " << Tipo << "'s." << endl;cout << "El mayor " << Tipo << " es ";return maxx;

}

int main() {int a=9, b=78, c=56;double d=100.8, e=89.9, f=349.7;cout << maximo(a,b,c) << endl;cout << maximo(d,e,f) << endl;return 0;

}

164



4.2 Polimorfismo en C++Abusos de RTTI (i)

Se debería utilizar la información de tipos en tiempo de ejecución explícita sólo cuando sea necesario

La verificación estática es más segura, implica menos sobrecarga y da lugar a programa mejor estructurados

Se deberían emplear funciones virtuales en lugar de RTTI para tratar la mayoría de los casos en los que se necesita la discriminación en tiempo de ejecución basada en el tipoSe debe evitar las sentencias switch finamente encubiertas con RTTI

83




165



4.2 Polimorfismo en C++Abusos de RTTI (ii)

// Abuso de RTTIvoid rota (const Figura& r) {

if (typeid(r) == typeid(Circulo) {// No hacer nada

}else if (typeid(r) == typeid(Triangulo) {

// Rota triángulo}else if (typeid(r) == typeid(Cuadrado) {

// Rota cuadrado}//…

166



5. Asociaciones, Agregaciones y Composiciones

Otras relaciones entre clases

84




167



5.1 AsociacionesIntroducción

Las asociaciones constituyen el tipo más general de relaciones entre clases, a la vez que son las construcciones de con mayor debilidad semánticaLa identificación de asociaciones entre clases es frecuentemente una actividad de análisis y de diseño preliminarA medida que se continúa el diseño y la implementación pueden refinarse, orientándolas hacia otras relaciones de clase más concretasEn el diseño debe formularse una estrategia para implementar las asociaciones, para lo cual debe analizarse la forma en que serán utilizadasNumerosas corrientes de modelado consideran a las asociaciones inherentemente bidireccionales [Rumbaugh et al., 1991], [Booch, 1994], [OMG, 2003]Si las asociaciones sólo se van a recorrer en una dirección, se puede simplificar su implementación

168



Si una asociación sólo se recorre en una dirección, es posible implementarla mediante un atributo que contenga una referencia a un objeto [Rumbaugh et al., 1991]

Si la multiplicidad es de “uno” se necesita una única referenciaSi la multiplicidad es “muchos” se requiere un conjunto de referencias

Si el extremo “muchos” está ordenado se puede utilizar una lista en lugar de un conjunto

Una asociación cualificada con multiplicidad “uno” se puede implementar en forma de objeto diccionario

Un diccionario es un conjunto de pares de valores que hacen corresponder valores del selector con valores del destino

5.1 AsociacionesDiseño (i)

85




169



Cuando las asociaciones se pueden recorrer en ambas direcciones, se pueden seguir tres aproximaciones para su implementación [Rumbaughet al., 1991]

Se implementan como un atributo en una dirección sólo, y se hace una búsqueda cuando se requiere un recorrido en la otra dirección

Esta aproximación sólo es útil si hay una gran disparidad entre las frecuencias de recorrido en los dos sentidos, y si además es importante minimizar el coste de almacenamiento y el de actualización

Se implementan como atributos en ambas direcciones, utilizando referencias

Esto permite un acceso rápido, pero si se actualiza alguno de los atributos también el otro atributo deberá actualizarse para mantener la congruencia del enlace, lo que conduce a una ruptura de la encapsulación. Esta aproximación es útil cuando el número de accesos supera al de las actualizaciones

Se implementan como un objeto de asociación por separado, independiente de ambas clases

Un objeto de asociación es un conjunto de parejas de objetos asociados

5.1 AsociacionesDiseño (ii)

170



Las asociaciones bidireccionales violan la encapsulación y comprometen la reutilización de las clases [Graham et al., 1997]

Proponen la utilización de asociaciones unidireccionales, mappings, que preserven la encapsulación, integrando en el objeto las reglas de negocio, accesibles a través de la interfaz de dicho objetoLos mappings unidireccionales se implementan como punteros embebidos en los objetos, acoplados con reglas que preserven la integridad semántica y referencial

5.1 AsociacionesDiseño (iii)

86




171



5.1 AsociacionesDiseño (iv)

Caso de estudio 1: Personas escriben Artículos

Artículo Persona* 1..*<escribe

Escribe

r1 r2¡¡ Viola la encapsulación !!

Artículo Persona1..*

* <escribe

escritos por >

Artículo Persona* 1..*<escribe

clase Artículo autor: Personaautor.escritosPor

clase Persona artículoEscrito: ArtículoartículoEscrito.participanEn

172



5.1 AsociacionesDiseño (v)

Caso de estudio 2: Personas se casan

PersonaMatrimonio

0..1

0..1

marido

esposa

Persona

Matrimonio

0..1

estáCasada

estáCasada2

estáFormado

87




173



La relación de uso es un posible refinamiento de una asociación, por el que se establece qué abstracción es el cliente y quéabstracción es el servidor que proporciona ciertos servicios [Booch, 1994]Es una relación cliente-servidorUna relación de uso está presente si un método toma una instancia de otra claseExiste una relación de uso si la lógica dentro de un método llama a los servicios de otra clase

5.2 Relación de uso

174



El concepto de amistad no sólo se da entre una función y una clase, también puede darse entre clasesEn este caso todas las funciones de la clase amiga pueden acceder a la parte privada de la otra claseLa declaración friend no se asocia ni a la sección privada ni a la sección pública de una clase

5.3 Asociaciones en C++Relaciones de amistad (i)

class A {

/* Parte privada de A */

public:

/* Parte pública de A */

friend class B;

};

88




175



Definir una clase como friend da acceso a los datos privados en una única dirección

Privado

Funcionesmiembro

B es friend

Clase A Clase BPrivado

Funcionesmiembro

5.3 Asociaciones en C++Relaciones de amistad (ii)

176



Una función amiga es una función no miembro de una clase que puede tener acceso a la parte privada de una claseNo se definen en la claseSe declaran situando su prototipo de función en la clase de la que son amigas precediéndolas de la palabra reservada friend

5.3 Asociaciones en C++Relaciones de amistad (iii)

89




177




#define SI 1#define NO 0

enum material {madera, cuero, aluminio, plastico, cristal};enum color {negro, azul, marron_oscuro, marron_claro, verde,

rojo, blanco, transparente, dorado, plateado};

class Mesa;

class Silla {color col;material mat;int patas;

public:Silla() {col=marron_oscuro; mat=madera; patas=4;}void PonColor (color c);void PonMaterial (material m);void PonPatas (int num);friend int MismoColor (Silla, Mesa);

};

5.3 Asociaciones en C++Relaciones de amistad (iv)

178



class Mesa {color col;material mat;int patas;

public:Mesa() {col=transparente; mat=cristal; patas=4;}void PonColor (color c);void PonMaterial (material m);void PonPatas (int num);friend int MismoColor(Silla, Mesa );

};void inline Silla::PonColor (color c) {

col=c;}void inline Silla::PonMaterial (material m) {

mat=m;}void inline Silla::PonPatas (int num) {

patas=num;}void inline Mesa::PonColor (color c) {

col=c;}void inline Mesa::PonMaterial (material m) {

mat=m;}void inline Mesa::PonPatas (int num) {

patas=num;}int MismoColor (Silla s, Mesa m) {

if (s.col == m.col ) return SI;return NO;

}

5.3 Asociaciones en C++Relaciones de amistad (v)

90




179



void main (void) {Silla s_comedor;Mesa m_salon, m_comedor;

m_comedor.PonColor(marron_oscuro);m_comedor.PonMaterial(madera);

if (MismoColor(s_comedor, m_salon) )cout << "\nLa silla y la mesa combinan.\n";

elsecout << "\nLa silla y la mesa no combinan.\n";

if (MismoColor(s_comedor, m_comedor) )cout << "\nLa silla y la mesa combinan.\n";

elsecout << "\nLa silla y la mesa no combinan.\n";

}

5.3 Asociaciones en C++Relaciones de amistad (vi)

180



¿Violan el encapsulamiento?Tres formas de verlas

No son funciones miembro, y por su mera existencia están violando el encapsulamiento, ya que tienen acceso a los datos privados de una claseEstán dentro de la barrera de encapsulamiento de la clasePuerta trasera que permiten un acceso irregular a los datos privados de la clase

VentajasClaridad sintáctica

DesventajasSe añaden al espacio de nombres globalNo se heredanNo responden al polimorfismo

5.3 Asociaciones en C++Relaciones de amistad (vii)

91




181



5.3 Asociaciones en C++Uso de punteros (i)

Se podrían implementar en C++ empleando punterosCada vez que se añade un enlace a la asociación, es preciso actualizar ambos punteros, igualmente cuando se elimina un enlaceLos métodos de Grupo van a poder actualizar el puntero miembro de Elemento

Violación de la encapsulación

Sea el siguiente ejemplo [Rumbaugh et al., 1991]

Grupo Elemento0..1 1..*

182



5.3 Asociaciones en C++Uso de punteros (ii)class Elemento {

private:Grupo *grupo;friend Grupo::add_elemento(Elemento *);friend Grupo::eliminar_elemento(Elemento *);

public:Grupo * obtener_grupo() {return grupo;}

};

class Grupo {private:

ConjuntoElementos *elementos;public:

void add_elemento(Elemento *);void eliminar_elemento(Elemento *);ConjuntoElementos * tomar_elementos(){return elementos;}

};

Hay otras formas de implementarcolecciones, sin tener que recurrira definir una nueva clase (ver STL)

class ConjuntoElementos {public:

ConjuntoElementos(); // Crear un conjunto vacío~ConjuntoElementos();void add(Elemento *);void eliminar(Elemento *);bool contiene(Elemento *);int size();

};

92




183



void Grupo::add_elemento(Elemento *elto) {elto->grupo = this;elementos->add(elto);

}

void Grupo::eliminar_elemento(Elemento *elto) {elto->grupo = 0;elementos->eliminar(elto);

}

5.3 Asociaciones en C++Uso de punteros (iii)

184



Se puede implementar una clase asociación como una nueva clase contenedoraSe puede implementar un objeto asociación como dos objetos diccionario

Uno de los diccionarios define la asociación en una dirección y el otro en la inversa

Los enlaces de la asociación son los elementos del objeto asociaciónEsta aproximación compromete la reutilización y el encapsulamiento de las clases

5.3 Asociaciones en C++Objetos Asociación

93




185



Sea el siguiente ejemplo [Booch, 1994]

ControladorTemperatura GradienteTemperatura

class ControladorTemperatura {public:

ControladorTemperatura(Posicion);~ControladorTemperatura();void procesar(const GrandienteTemperatura&);Minuto planificar(const GrandienteTemperatura&) const;

private:Calentador c;

};

5.4 Relación de uso en C++

186



5.5 Relación de AgregaciónIntroducción (i)

Relaciones todo/parteUna relación todo/parte es una forma fuertemente acoplada de asociación, con una cierta cantidad de semántica adicionalSon relaciones transitivas, esto es, si A es parte de B y B es parte de C, entonces A es parte de CSon relaciones antisimétricas, si A es parte de B, entonces B no es parte de AEn OMT [Rumbaugh et al., 1991], el método de Booch [Booch, 1994] y UML 1.x [OMG, 2003] las relaciones todo/parte son bidireccionales, frente al enfoque de OML donde son unidireccionales [Firesmith et al., 1998]En UML 1.x [OMG, 2003] se distingue entre agregación y composición

94




187



La agregación es una relación más relajada, donde los tiempos de vida del objeto todo y de los objetos partes ya no están tan estrechamente ligados

Se pueden crear y destruir instancias de cada clase involucrada en la relación de forma independienteEs posible que las partes sean compartidas estructuralmente(agregación compartida)

Hay que decidir alguna política por la que su espacio de almacenamiento sea correctamente creado y destruido por sólo uno de los agentes que comporten referencia a cada una de las partes

Se permiten relaciones de agregación reflexivas

5.5 Relación de AgregaciónIntroducción (ii)

188



5.6 Agregación en C++


ControladorTemperatura Calentador



private:Calentador *c; // Calentador &c; como otra opción

};Se tiene un puntero (o una referencia) a cada una de las partes

95




189



5.7 Relación de ComposiciónIntroducción

La composición indica una contención física, de manera que el objeto compuesto (todo) contiene físicamente a cada uno de sus objetos componentes (partes)El tiempo de vida de los objetos componentes está íntimamente ligado

Cuando se crea una instancia del compuesto se crea una instanciade cada componente (opcionalmente)Cuando se destruye la instancia del compuesto se destruyen las instancias de cada componente

No se permiten relaciones de composición reflexivas

190



5.8 Composición en C++ (i)


ControladorTemperatura Calentador



private:Calentador c;

};Se tiene un atributo que represente una instancia por cada una de las partes

96




191



#include <iostream.h>#include <string.h>class Fecha {

int mes, dia, agno;public:

Fecha(int m, int d, int a); // Constructor~Fecha(); //Destructor

int LeeDia(void) const;int LeeMes(void) const;int LeeAgno(void) const;

void EscribeDia(int d);void EscribeMes(int m);void EscribeAgno(int a);

void MuestraFecha(void) const;};

5.6 Composición en C++ (ii)

192



class Ficha {char nombre[50];char direccion[75];char telefono[15];const Fecha cumple;

public:Ficha(char *n, char *dir, char *t, int d, int m, int a);~Ficha();char *LeeNombre(void) const;char *LeeDireccion(void) const;char *LeeTelefono(void) const;

void EscribeNombre(char *n);void EscribeDireccion(char *d);void EscribeTelefono(char *t);void MuestraFicha(void) const;

};

5.6 Composición en C++ (iii)

97




193



// Funciones miembro de la clase Fecha

Fecha::Fecha(int d, int m, int a) {dia=d; mes=m; agno=a;cout << "C de Fecha" << endl;

}Fecha::~Fecha() {cout << "D de Fecha" << endl;}inline int Fecha::LeeDia(void) const {

return dia;}inline int Fecha::LeeMes(void) const {

return mes;}inline int Fecha::LeeAgno(void) const {

return agno;}inline void Fecha::EscribeDia(int d) {

dia=d;}inline void Fecha::EscribeMes(int m) {

mes=m;}inline void Fecha::EscribeAgno(int a) {

agno=a;}inline void Fecha::MuestraFecha(void) const {

cout << dia << "/" << mes << "/" << agno << "\n";}

5.6 Composición en C++ (iv)

194



// Funciones miembro de la clase Ficha

Ficha::Ficha(char *n, char *dir, char *t,int d, int m, int a):cumple(d, m, a) { // Inicio del miembro

strncpy(nombre, n, 50);strncpy(direccion, dir, 75);strncpy(telefono, t, 15);cout << "C de Ficha" << endl;

}Ficha::~Ficha() {cout << "D de Ficha" << endl;}inline char *Ficha::LeeNombre(void) const {

return (char *)nombre;}inline char *Ficha::LeeDireccion(void) const {

return (char*) direccion;}inline char *Ficha::LeeTelefono(void) const {

return (char*) telefono;}inline void Ficha::EscribeNombre(char *n) {

strncpy(nombre, n, 50);}

5.6 Composición en C++ (v)

98




195



inline void Ficha::EscribeDireccion(char *d) {strncpy(direccion, d, 75);

}inline void Ficha::EscribeTelefono(char *t) {

strncpy(telefono, t, 15);}inline void Ficha::MuestraFicha(void) const {

cout << "\nNombre:\t\t" << nombre;cout << "\nDireccion:\t" << direccion;cout << "\nTelefono:\t" << telefono;cout << "\nCumpleaños:\t" << cumple.LeeDia()

<< "/" << cumple.LeeMes() << "/"<< cumple.LeeAgno() << "\n";

}

void main(void) {Ficha M(“Carmen Crespo", “Av. De Portugal", "229927", 3, 5, 1970);M.MuestraFicha();M.EscribeTelefono("226531");M.MuestraFicha();

}

5.6 Composición en C++ (vi)

196



En la sección privada del la clase Ficha se tiene un miembro con el nombre de cumple que es un objeto Fecha. No tiene argumentos, pero esto no significa que se llame a un constructor por defecto. El objeto cumple no será construido hasta que un objeto de la clase Ficha sea construidoPara llamar al constructor del objeto miembro se debe especificar un miembro de inicio. Después de la lista de parámetros del constructor de la clase, se ponen ':' y seguidamente el nombre del miembro y la lista de argumentos (ver la definición del constructor de la clase Ficha)Esta sintaxis fuerza que el constructor de la clase Fecha sea invocado para el miembro cumple, usando los tres argumentos especificados. El constructor de la clase Fecha es llamado primero, y en consecuencia el miembro cumple se inicia antes de que se ejecute el constructor de la clase FichaSi no se utiliza un miembro de inicio, el compilador utilizará el constructor por defecto, y luego pueden asignarse los valores utilizando las funciones miembro adecuadas. Si no se ha definido un constructor por defecto el compilador generará un error. Esta técnica no es eficiente pues se inician los valores de cumple dos veces, una con el constructor por defecto y otra con las funciones miembroUn miembro de inicio es requerido cuando se tenga un objeto miembro constante. En este caso omitir el miembro que inicie es fatal, ya que no se pueden cambiar los valores que establezca el constructor por defecto

5.6 Composición en C++ (vii)

99




197



6. Interfaces

198



6.1 Concepto de InterfazUna interfaz puede definirse como un conjunto de operaciones referenciado por un nombre y que caracteriza el comportamiento de un elemento [OMG, 2003]Las interfaces son una forma de declarar un tipo que se compone sólo de métodos abstractos, posibilitando que se escriba cualquier implementación para estos métodosUna interfaz es una expresión de diseño puro, mientras que una clase es una mezcla de diseño e implementaciónJava incluye un mecanismo sintáctico para la definición de interfacesC++ no incluye ningún mecanismo sintáctico para la definición de interfaces, pero se podría simular utilizando clases abstractas puras (clases de interfaz)

100




199



Las interfaces son una forma de declarar un tipo que se compone sólo de métodos abstractos y constantesUna clase puede implementar los métodos de una interfaz de cualquier forma que elija el diseñador de la claseJava tiene herencia simple de implementación (clases) pero permite la herencia múltiple de interfacesTodos los métodos de una interfaz son implícitamente abstractosUna clase que implemente una interfaz debe implementar todos los métodos o ser declarada abstractaLos métodos de una interfaz son siempre públicos y no pueden ser estáticosLos atributos de una interfaz son siempre static y final

6.2 Interfaces en Java (i)

200



Una interfaz se define en Java

interface nombre_interfaz {tipo_devuelto nombre_método (lista_parámetros_formales);tipo nombre_variable_final = valor;

}

Clase que implementa una o más interfaces

class nombre_clase [extends nombre_superclase]implements interfaz1 [, interfaz2... ]

{cuerpo_clase

}

6.2 Interfaces en Java (ii)

101




201



En una clase dada, las clases que se extienden y las interfaces que se implementan reciben el nombre colectivo de supertiposDesde el punto de vista de los supertipos la nueva clase es un subtipoEl tipo completo de la nueva clase incluye todos sus supertipos, de modo que una referencia a un objeto de su tipo puede usarse de manera polimórfica, esto es, en cualquier lugar en que se necesite una referencia a un objeto de cualquiera de sus supertipos (clase o interfaz)Las definiciones de interfaz crean nombres de tipo igual que lasdefiniciones de clase

Se puede usar el nombre de una interfaz como nombre de tipo de una variable y cualquier objeto que implemente esa interfaz se puede asignar a esa variable

6.2 Interfaces en Java (iii)

202



Ejemplo de interfaces

6.2 Interfaces en Java (iv)

+push(in double)+pop() : double+vacia() : bool

«interface»Pila +push(in double)

+pop() : double+vacia() : bool

-valor : doublePilaEnlazada

-anterior0..1

-siguiente

0..1

Pila

Main

102




203



interface Pila {void push (int x);int pop();boolean vacia();

}class PilaEnlazada implements Pila {

private int valor;PilaEnlazada siguiente;public void push (int x) {

PilaEnlazada tmp;tmp = new PilaEnlazada();tmp.valor = x;tmp.siguiente = this.siguiente; this.siguiente = tmp;

}public int pop () {

int valor = this.siguiente.valor;this.siguiente=this.siguiente.siguiente;return valor;

}public boolean vacia() {

return siguiente == null;}

}

6.2 Interfaces en Java (v)

204



class Main {public static void main (String []args) {

Pila p = new PilaEnlazada();

for (int i=0; i<10; i++) {p.push(i);p.push(20-i);

}while (!p.vacia())

System.out.println(p.pop());}

}

119128137146155164173182191200

6.2 Interfaces en Java (vi)

103




205



Extensión de interfacesLas interfaces también se pueden extender mediante la palabra clase extendsLas interfaces pueden extender más de una interfazAl tener herencia múltiple se tienen posibles conflictos de nombre

Si los métodos tienen distinta signatura, no hay problemasSólo hay problemas si tienen los mismos argumentos pero devuelven tipos distintos

6.2 Interfaces en Java (vii)

206



W

X Y

Z

W

X Y

Zinterface W { }interface X extends W { }class Y implements W { }class Z extends Y implements X { }

interface W { }interface X extends W { }interface Y extends W { }class Z implements X, Y { }

6.2 Interfaces en Java (viii)

104




207



ConclusionesJava presenta una aproximación al hecho de que la interfaz y la implementación son físicamente cosas distintasAunque si se restringen los diseños a la herencia simple, no existe una verdadera necesidad del uso de las interfaces en Java, porque cada clase implícitamente tiene una interfaz, sin la necesidad de declarar una interfaz explícita; cumpliéndose la afirmación de que cada clase presenta una interfaz a sus usuarios [Stroustrup, 1997]

6.2 Interfaces en Java (ix)

208



7. Módulos

105




209



7.1 IntroducciónSe discuten dos temas fundamentales, y muy relacionados entre sí:

El agrupamiento lógico y físico de las clases, yLa distinción entre interfaz e implementación

El módulo lógico básico en la mayoría de los sistemas orientados a objetos es la clase, aunque para la mejor gestión y reutilización de estas clases deben organizarse en elementos de mayor grano, como se apunta desde la bibliografía especializada

Categoría, componente, espacio de nombres, cluster, paquete

Físicamente, los lenguajes más extendidos organizan sus clases en ficheros, y éstos a su vez en directoriosHasta aquí las semejanzas, derivadas todas ellas por el concepto recurrente de clase, presente en todos los lenguajes de programación orientados a objetos de una manera similar

Sin embargo, los lenguajes difieren en gran medida a la hora de organizar las clases en módulos físicos

210



Nombre

NombreNombre Nombre

7.2 Modularidad en UML (i)Paquetes

Un paquete es un grupo de elementos del modelo que pueden a su vez anidarse Su utilidad final es ganar claridad cuando un modelo se complica a costa de perder detalles

Detalles que, posteriormente, se podrán obtener al abrir el paquete

Un paquete se expresa a través de un rectángulo con una pestaña en su parte superior izquierda

106




211



Banca::CuentaCorriente

Clientes

CuentaCorriente

Banca<<imports>>

7.2 Modularidad en UML (ii)Importación de paquetes

Se puede hacer referencia a una clase de otro paqueteLa importación a nivel de paquete indica qué paquetes contienen las clases referenciadas por el paquete, o recursivamente, quépaquetes contienen paquetes que a su vez contienen clases referenciadasLa dependencia de importación se expresa a través de una flecha de dependencia con el estereotipo «imports»

212



7.3 Modularidad en C++

C++ hereda de C su organización de módulosSe suelen colocar las interfaces de los módulos en archivos cabecera (.h)Las implementaciones de los módulos se sitúan en archivos de implementación (.cpp, .cc)Las dependencias entre módulos se declaran mediante directivas de inclusiónSe tiene el concepto de espacio de nombre para ofrecer un mayor control sobre los módulos

107




213



Un programa incluye varios identificadores definidos en distintos ámbitosA veces un variable de un ámbito se sobrepone a una variable del mismo nombre en un ámbito diferente, dando lugar a un problema potencialEl estándar ANSI/ISO de C++ intenta solucionar este problema con los espacios de nombresCada espacio de nombres define un ámbito donde se colocan los identificadores y las variables globalesUn espacio de nombres es, por tanto, un mecanismo para expresar agrupamiento lógico [Stroustrup, 1997]

Es decir, si algunas declaraciones comparten desde el punto de vista lógico algunos criterios, pueden ponerse en un espacio de nombres común para expresar ese hecho

7.3 Modularidad en C++Espacios de nombres (i)

214



Los miembros de un espacio de nombres deben ser introducidos usando la siguiente construcción sintáctica

namespace <nombre> {// declaraciones y definiciones

}No se pueden declarar nuevos miembros de un espacio de nombres fuera de la definición del espacio de nombresLas reglas normales de ámbito son válidas para los espacios de nombres

Si un nombre es declarado previamente en un espacio de nombres o en un ámbito inclusivo puede ser usado sin másUn nombre de otro espacio de nombres puede ser usado cuando está cualificado por el nombre de su espacio de nombres

Cuando se utiliza frecuentemente un nombre fuera de su espacio de nombres es tedioso cualificarlo constantementeEsta repetición se puede eliminar usando una declaración using

Permite acceder a todos los miembros del espacio de nombres escribiendo sentencias más concisas

Una declaración using introduce un sinónimo local

7.3 Modularidad en C++Espacios de nombres (ii)

108




215



7.3 Modularidad en C++Espacios de nombres (iii)

// Ejemplo del uso de los espacios de nombres#include <iostream>

int ejemplo=100; // Variable global

namespace Externo {const double PI = 3.14159;const double E = 2.71828;int ejemplo = 9;void muestraValores();

namespace Interno { // Espacio de nombres anidadoenum Agnos {FISCAL1 = 1998, FISCAL2, FISCAL3};

}}

namespace { // Espacio de nombres sin nombredouble d = 90.8;

}void Externo::muestraValores() {

cout << endl << "PI = " << PI << endl << "E = " <<E << endl << "ejemplo (Externo) = " << ejemplo <<endl << "ejemplo (global) = " << ::ejemplo <<endl << "FISCAL3 = " << Interno::FISCAL3 << endl;

}

216



7.3 Modularidad en C++Espacios de nombres (iv)void main() {

// Salida de la variable d del espacio de nombres sin nombre// Existe una directiva using implícitacout << "d = " << d << endl;

// Salida de la variable globalcout << "ejemplo (global) = " << ejemplo << endl;

// Salida de los valores del espacio de nombres Externocout << endl << "PI = " << Externo::PI << endl << "E = " <<

Externo::E << endl << "ejemplo (Externo) = " << Externo::ejemplo <<endl << "FISCAL3 = " << Externo::Interno::FISCAL3 << endl;

// Utilizando usingusing namespace Externo;cout << endl << "PI = " << PI << endl << "E = " <<

E << endl << "ejemplo (Externo) = " << Externo::ejemplo <<endl << "ejemplo (global) = " << ::ejemplo <<endl << "FISCAL3 = " << Interno::FISCAL3 << endl;

// Utilizando la función Externo::muestraValores()muestraValores();

}

d = 90.8ejemplo (global) = 100

PI = 3.14159E = 2.71828ejemplo (Externo) = 9FISCAL3 = 2000

PI = 3.14159E = 2.71828ejemplo (Externo) = 9ejemplo (global) = 100FISCAL3 = 2000

PI = 3.14159E = 2.71828ejemplo (Externo) = 9ejemplo (global) = 100FISCAL3 = 2000

109




217



7.3 Modularidad en C++Espacios de nombres (v)

namespace Ejemplo1 {class E1 {

int a;public:

E1():a(0){};E1(int a) {this->a=a;}void set_a(int a) {this->a=a;}int get_a(){return a;}void suma(int);

};}

miclase.h

#include "miclase.h"

void Ejemplo1::E1::suma(int x) {a+=x;}

miclase.cc

namespace Ejemplo2 {class E1 {

double a;public:

E1():a(0.0){};E1(double a) {this->a=a;}void set_a(double a) {this->a=a;}double get_a(){return a;}void resta(double);

};}

tuclase.h

#include "tuclase.h"

void Ejemplo2::E1::resta(double x) {a-=x;}

tuclase.cc

#include "miclase.h"#include "tuclase.h"#include <iostream>

void main(void) {Ejemplo1::E1 e1;Ejemplo2::E1 e2(9.0);

e1.set_a(89);cout << e1.get_a() << endl;

e2.resta(1);cout << e2.get_a() << endl;

}

89

8

218



PaquetesLos paquetes son recipientes con clases para mantener el espacio de nombres de clase dividido en compartimentosLos paquetes tienen una estructura jerárquica, de forma que el paquete a.b.c está contenido en el paquete a.bLos paquetes se importan de forma explícitaLos paquetes proporcionan un mecanismo de restricción de visibilidad, de manera que se pueda indicar que ciertos elementos son sólo accesibles en su propio paqueteLa sentencia package sirve para indicar el paquete en el se está

7.4 Modularidad en Java (i)

110




219



7.4 Modularidad en Java (ii)Paquetes

Estructura general de un archivo JavaUna única sentencia opcional de paquete, donde se indica el paquete en el que se enmarca el ficheroLas sentencias de importación deseadas (opcional)Una única declaración de clase públicaLas clases privadas del paquete (opcional)

La estructura jerárquica se debe reflejar en el sistema de ficheros. Así, el paquete a.b.c exige la presencia de un directorio denominado a con subdirectorio llamado b...No se puede renombrar un paquete sin cambiarlo de directorioLa sentencia import sirve para indicar que elementos se quieren utilizar

import paquete1.[paquete2].(nombre_clase | *);Se pueden indicar clases de un paqueteSe pueden indicar todas las clases con un “*”

220



Protección de accesoJava proporciona muchos niveles de protección para permitir un control preciso de la visibilidad de las variables y métodosLas clases y los paquetes son dos medios para encapsular y contener el espacio de nombres y el ámbito de las variables y métodosDentro de una clase, todas las variables y métodos son visibles para todas las partes de la claseLa existencia de paquetes implica que se tengan que distinguir cuatro categorías de visibilidad entre elementos de clase

Subclases del mismo paqueteNo subclases del mismo paqueteSubclases en distintos paquetesClases que no están ni en el mismo paquete ni en las subclases

7.4 Modularidad en Java (iii)

111




221



Protección de accesoLas palabras clave private, public y protected se combinan de diferentes maneras

private sin modificador protected public

Misma clase Sí Sí Sí Sí Subclase del mismo paquete No Sí Sí Sí

No subclase del mismo paquete No Sí Sí Sí

Subclase de diferente paquete

No No Sí Sí

No subclase de diferente paquete

No No No Sí

7.4 Modularidad en Java (iv)

222



package p1;

public class Proteccion {int n=1;private int n_pri = 2;protected int n_pro = 3;public int n_pub = 4;

public Proteccion() {System.out.println("Constructor base");System.out.println("n = " + n);System.out.println("n_pri = " + n_pri);System.out.println("n_pro = " + n_pro);System.out.println("n_pub = " + n_pub);

}}

Proteccion.javapackage p1;

public class Derivada extends Proteccion {public Derivada() {

System.out.println("Constructor derivado");System.out.println("n = " + n);// Sólo desde la clase// System.out.println("n_pri = " + n_pri);System.out.println("n_pro = " + n_pro);System.out.println("n_pub = " + n_pub);

}}

Derivada.java

package p1;

public class MismoPaquete {public MismoPaquete() {

Proteccion p = new Proteccion();System.out.println("Constructor del mismo paquete");System.out.println("n = " + p.n);// Sólo desde la clase// System.out.println("n_pri = " + p.n_pri);System.out.println("n_pro = " + p.n_pro);System.out.println("n_pub = " + p.n_pub);

}}

MismoPaquete.java

7.4 Modularidad en Java (v)

112




223



package p2;

public class Proteccion2 extends p1.Proteccion {public Proteccion2() {

System.out.println("Constructor de otro paquete derivado");// Sólo desde la clase o paquete// System.out.println("n = " + n);// Sólo desde la clase// System.out.println("n_pri = " + n_pri);System.out.println("n_pro = " + n_pro);System.out.println("n_pub = " + n_pub);

}}

Proteccion2.java

package p2;public class OtroPaquete {

public OtroPaquete() {p1.Proteccion p = new p1.Proteccion();System.out.println("Constructor de otro paquete");// Sólo desde la clase o paquete// System.out.println("n = " + p.n);// Sólo desde la clase// System.out.println("n_pri = " + p.n_pri);// Sólo desde la clase, subclase o paquete// System.out.println("n_pro = " + p.n_pro);System.out.println("n_pub = " + p.n_pub);

}}

OtroPaquete.java

7.4 Modularidad en Java (vi)

224



import p1.*;import p2.*;

class pp {public static void main(String args[]) {

Proteccion p = new Proteccion();Derivada d = new Derivada();MismoPaquete m = new MismoPaquete();Proteccion2 p2 = new Proteccion2();OtroPaquete o = new OtroPaquete();

}}

pp.javaConstructor basen = 1n_pri = 2n_pro = 3n_pub = 4Constructor basen = 1n_pri = 2n_pro = 3n_pub = 4Constructor derivadon = 1n_pro = 3n_pub = 4Constructor basen = 1n_pri = 2n_pro = 3n_pub = 4Constructor del mismo paqueten = 1n_pro = 3n_pub = 4Constructor basen = 1n_pri = 2n_pro = 3n_pub = 4Constructor de otro paquete derivadon_pro = 3n_pub = 4Constructor basen = 1n_pri = 2n_pro = 3n_pub = 4Constructor de otro paqueten_pub = 4

7.4 Modularidad en Java (vii)

113




225



8. Principios de DOO

226



Las entidades software (clases, módulos, funciones...) deben estar abiertas para su extensión, pero cerradas

para su modificaciónBertrand Meyer [Meyer, 1997]

Las entidades software (clases, módulos, funciones...) deben estar abiertas para su extensión, pero cerradas

para su modificaciónBertrand Meyer [Meyer, 1997]

8.1 El principio abierto/cerrado (i)

Los módulos que satisfacen el principio abierto/cerrado cumplen que

Están abiertos para su extensiónEsto implica que el comportamiento de los módulos puede ser extendido Se puede hacer que un módulo se comporte de formas nuevas cuando los requisitos de la aplicación cambien

Están cerrados para su modificaciónEl código fuente del módulo es inalterable. No se permite realizar cambios al código fuenteEl módulo está cerrado a las modificaciones que afecten a los clientes

114




227



La clave del principio abierto/cerrado está en la abstracciónLa clave del principio abierto/cerrado está en la abstracción

Cliente Servidor

Diseño que no se ajusta al principio abierto/cerrado

Diseño que cumple el principio abierto/cerrado

8.1 El principio abierto/cerrado (ii)

Cliente ServidorAbstracto<<Abstracta>>

Servidor

228



8.1 El principio abierto/cerrado (iii)

El principio abierto/cerrado es en esencia equivalente al patrón Variaciones Protegidas

Variaciones Protegidas explica cómo diseñar objetos, subsistemas y sistemas de forma que las variaciones o inestabilidades en estoselementos no tengan un impacto no deseable en otros elementos

La diferencia está en el punto de vista que resalta cada unoLas variaciones protegidas se centra en los puntos de variaciónEl principio abierto/cerrado se centra en la evolución

En el contexto del principio abierto/cerrado, la frase “cerrado con respecto a X” significa que los clientes no se ven afectados si X cambia [Larman, 2002]

115




229



Lo que se quiere aquí es algo como la siguiente propiedad de sustitución: Si para cada objeto o1 de tipo S hay un objeto o2 de tipo T tal que para todos los programas P definidos en términos de T, el comportamiento de P no

cambia cuando o2 es sustituido por o1, entonces S es un subtipo de T

Barbara Liskov (1987)

Lo que se quiere aquí es algo como la siguiente propiedad de sustitución: Si para cada objeto o1 de tipo S hay un objeto o2 de tipo T tal que para todos los programas P definidos en términos de T, el comportamiento de P no

cambia cuando o2 es sustituido por o1, entonces S es un subtipo de T

Barbara Liskov (1987)

8.2 El principio de sustitución de Liskov (i)

Informalmente, el software (métodos, clases…) que hace referencia a un tipo T (alguna interfaz o superclase abstracta) debería trabajar correctamente o como se espera con cualquier implementación o subclase S de T que la sustituyaLas clases derivadas deben ser utilizables a través de la interfaz de la clase base, sin necesidad de que el usuario conozca la diferencia

En C++, las funciones que usan punteros o referencias a clases base deben ser capaces de utilizar objetos de las clases derivadas sin tener conocimiento de ello

230



class Rectangulo {double alto, ancho;

public:Rectangulo(double _alto, double _ancho) {alto=_alto; ancho=_ancho;}void EstableceAlto(double tmp) {alto=tmp;}void EstableceAncho(double tmp) {ancho=tmp;}double Alto() const {return alto;}double Ancho() const {return ancho;}

};

class Cuadrado: public Rectangulo {public:

Cuadrado(double lado):Rectangulo(lado, lado){}void EstableceAlto(double lado) {

Rectangulo::EstableceAlto(lado);Rectangulo::EstableceAncho(lado);

}void EstableceAncho(double lado) {


}};

8.2 El principio de sustitución de Liskov (ii)

Rectangulo

Cuadrado

116




231



void main (void) {Cuadrado c1(2);cout << c1.Alto() << " " << c1.Ancho() << endl; //Salida: 2 2

c1.EstableceAlto(5);cout << c1.Alto() << " " << c1.Ancho() << endl; //Salida 5 5

c1.EstableceAncho(10);cout << c1.Alto() << " " << c1.Ancho() << endl; //Salida 10 10

}

Este programa funcionará sin problemas

8.2 El principio de sustitución de Liskov (iii)

232



Pero, ¿qué sucedería con alguna función que recibiese una referencia o un puntero a un objeto Rectangulo y

modificase su altura o su anchura?

void CambiaAspecto(Rectangulo &r) {r.EstableceAncho(r.Alto()*.5);

}

void main (void) {Rectangulo r1(8, 7);cout << r1.Alto() << " " << r1.Ancho() << endl; //Salida: 8 7CambiaAspecto(r1);cout << r1.Alto() << " " << r1.Ancho() << endl; //Salida: 8 4Cuadrado c1(2);cout << c1.Alto() << " " << c1.Ancho() << endl; //Salida: 2 2CambiaAspecto(c1);cout << c1.Alto() << " " << c1.Ancho() << endl; //Salida: 2 1

}

8.2 El principio de sustitución de Liskov (iv)

117




233



class Rectangulo {double alto, ancho;

public:Rectangulo(double _alto, double _ancho) {alto=_alto; ancho=_ancho;}virtual void EstableceAlto (double tmp) {alto=tmp;}virtual void EstableceAncho(double tmp) {ancho=tmp;}double Alto() const {return alto;}double Ancho() const {return ancho;}

};class Cuadrado: public Rectangulo {public:

Cuadrado(double lado): Rectangulo(lado, lado){}virtual void EstableceAlto(double lado) {


}virtual void EstableceAncho(double lado) {


}};

void main (void) {Cuadrado c1(2);cout << c1.Alto() << " " << c1.Ancho() << endl; //Salida: 2 2

CambiaAspecto(c1);cout << c1.Alto() << " " << c1.Ancho() << endl; //Salida: 1 1

}

8.2 El principio de sustitución de Liskov (v)

234



void CambiaAspecto(Rectangulo &r) {if (typeid(r) == typeid(Cuadrado))

throw "\nNo se puede ajustar el aspecto de un cuadrado";r.EstableceAncho(r.Alto()*.5);

}

8.2 El principio de sustitución de Liskov (vi)

ConclusionesUn modelo, visto por separado, no puede ser validado La validez de un modelo sólo puede expresarse en términos de sus clientesUn cuadrado puede ser un rectángulo, pero un objeto Cuadradono es un objeto Rectangulo porque, en términos de comportamiento, el comportamiento de un objeto Cuadrado no es consistente con el comportamiento de un objeto Rectangulo

118




235



Existe una fuerte relación entre el principio de Liskov y el concepto de diseño por contrato expuesto por Bertrand Meyer

Existe una fuerte relación entre el principio de Liskov y el concepto de diseño por contrato expuesto por Bertrand Meyer

“... cuando se redefine un método (en una clase derivada), sólo se puede reemplazar su precondición por una más suave,

y su poscondición por una más fuerte”Bertrand Meyer

8.2 El principio de sustitución de Liskov (vii)

236



8.3 Ley de Demeter (i)Es un principio que enuncia un diseño de ocultación de la estructuraLa Ley de Demeter [Lieberherr et al., 1988] o el patrón No hable con extraños [Larman, 1999] establece que los diseños que por evitar recorrer largos caminos de la estructura de objetos envían mensajes a objetos distantes, indirectos (extraños), son diseños frágiles con respecto a los cambios en las estructuras de los objetos

Esto es un punto frecuente de inestabilidad

Este principio restringe los objetos a los que se debería enviar los mensajes dentro de un método, de forma que sólo se deberían enviar mensajes a los siguientes objetos

El objeto this (o self)Un parámetro del métodoUn atributo de thisUn elemento de una colección que es un atributo de thisUn objeto creado en el método

119




237



8.3 Ley de Demeter (ii)

La intención es evitar el acoplamiento de un cliente con conocimiento de objetos indirectos y las conexiones entre objetosUn cliente debería “hablar” sólo con objetos directos y evitar hacerlo con objetos indirectos

Los objetos directos son “conocidos” del clienteLos objetos indirectos son “extraños” para el cliente

238



8.3 Ley de Demeter (iii)

Este código recorre conexiones estructurales a partir de un objeto conocido (venta) hasta un objeto extraño (pago), y entonces le envía un mensajeEs un método ligeramente frágil ya que depende de que los objetos Venta se conecten a los objetos Pago

class Registro {private Venta venta;

public void metodoFragil {Dinero cantidad = venta.getPago().getCantidadEntregada();

//…}

}

120




239



8.3 Ley de Demeter (iv)Sea el siguiente ejemplopublic void metodoMasFragil {

TitularCuenta titular =venta.getPago().getCuenta().getTitularCuenta();

//…}

Este diseño está acoplado a una estructura particular de cómo están conectados los objetos

Un programa es más frágil cuanto más lejos recorre un camino de objetos

No siempre es necesario proteger contra esto, depende de la inestabilidad de la estructura de los objetos [Larman, 2002]

En sistemas maduros, la estructura es más estable, en sistemas nuevos, en las primeras iteraciones, no es estable

240



8.4 El principio de inversión de dependencia (i)

Un software que cumple sus requisitos pero que presenta alguna, o todas, de las características siguientes tiene un mal diseño

RigidezEs difícil de cambiar porque cada cambio tiene demasiados efectos en otras partes del sistema

FragilidadCuando se realiza un cambio, partes inesperadas del sistema dejan de funcionar

InmovilidadEs difícil de reutilizar en otras aplicaciones porque no puede separarse de la aplicación actual

La interdependencia de los módulos dentro de un diseño es lo que provoca que un diseño sea rígido, frágil e inmóvil

121




241



A. Los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depender de las

abstraccionesB. Las abstracciones no deben depender de los detalles.

Los detalles deben depender de las abstraccionesRobert C. Martin

A. Los módulos de alto nivel no deben depender de los módulos de bajo nivel. Ambos deben depender de las

abstraccionesB. Las abstracciones no deben depender de los detalles.

Los detalles deben depender de las abstraccionesRobert C. Martin

8.4 El principio de inversión de dependencia (ii)

tecla

Copiar

LeerTeclado EscribeFichero

tecla fichero

Como ejemplo se va a tomar un programa que va a tener la misión de mandar los caracteres que se introduzcan por el

teclado a un fichero en disco

242



#include <stdio.h>#include <conio.h>#include <stdlib.h>

void Copiar(char *);char LeerTeclado(void);void EscribeFichero(char *, char);

void Copiar(char *cad) {char tecla;while ((tecla = LeerTeclado()) != EOF)

EscribeFichero(cad,tecla);}

char LeerTeclado(void) {char tecla;tecla=getch();tecla != 13 ? printf("%c", tecla) : printf("\n");return tecla;

}

void EscribeFichero(char *fichero, char tecla) {FILE *out;if ((out = fopen(fichero, "a+")) == NULL) {

fprintf(stderr, "Error al crear el fichero.\n");exit(-1);

}tecla != 13 ? fprintf(out, "%c", tecla) : fprintf(out, "\n");fclose(out);

}

void main(void) {Copiar("pp.txt");

}

8.4 El principio de inversión de dependencia (iii)

122




243



/* Tipos de dispositivos */enum Dispositivo {disco, impresora};

/* ................................*/

void Copiar(enum Dispositivo dev, char *cad) {char tecla;

while ((tecla = LeerTeclado()) != EOF)if (dev==disco)

EscribeFichero(cad,tecla);else

EscribeImpresora(tecla);}

8.4 El principio de inversión de dependencia (iv)

244



De esta forma ahora se puede reutilizar la clase Copiar de forma independiente de los dispositivos físicos

8.4 El principio de inversión de dependencia (v)Copiar

Lector Escritor

Lector deTeclado

Escritor enDisco

123




245



#include <iostream.h>#include <fstream.h>#include <string.h>

class Lector {public:

virtual char leer() = 0;};

class Escritor {public:

virtual void escribir(char) = 0;};

class LectorTeclado : public Lector {public:

virtual char leer() {char tecla;cin.get(tecla);return tecla;

}};

8.4 El principio de inversión de dependencia (vi)

void Copiar(Lector& l, Escritor& e) {char tecla;while ((tecla=l.leer()) != EOF)

e.escribir(tecla);};void main (void) {

EscritorFichero E1("pp.txt");LectorTeclado L1;

Copiar (L1, E1);}

class EscritorFichero :public Escritor {char nombre[25];

public:EscritorFichero(char *cad) {

strcpy(nombre,cad);}virtual void escribir(char tecla) {

fstream fichero;fichero.open(nombre, ios::app);fichero << tecla;fichero.close();

}};

246



Los clientes no deben ser forzados a depender de interfaces que no utilizan

Robert C. Martin

Los clientes no deben ser forzados a depender de interfaces que no utilizan

Robert C. Martin

8.5 El principio de separación de la interfaz (i)

class Puerta {public:

virtual void Candada() = 0;virtual void Descandada() = 0;virtual int EstaAbierta() = 0;

};

La clase Puerta es una clase abstracta, por lo tanto los clientes de la misma podrán utilizar objetos que cumplan la interfaz de la clase Puerta, con total independencia de las implementaciones de las

puertas específicas

124




247



class ClienteTemporizador {public:

void Registro(int tiempo, Temporizador* t);};class Temporizador {public:

virtual void TimeOut() = 0;};

8.5 El principio de separación de la interfaz (ii)

Temporizador ClienteTemporizador

Puerta

PuertaConAlarma

248



8.5 El principio de separación de la interfaz (iii)

Puerta ClienteTemporizador

PuertaConAlarma

125




249



La granularidad de la reutilización es la granularidad de la revisión. Sólo los componentes que son revisados a través de un sistema de distribución pueden ser reutilizados de

forma efectiva. Este grano es el paqueteRobert C. Martin

La granularidad de la reutilización es la granularidad de la revisión. Sólo los componentes que son revisados a través de un sistema de distribución pueden ser reutilizados de

forma efectiva. Este grano es el paqueteRobert C. Martin

8.6 El principio de equivalencia reutilización/revisión

250



La estructura de dependencia entre los paquetes debe ser un grafo dirigido acíclico (DAG). Esto es, no debe

haber ciclos en la estructura de dependenciaRobert C. Martin

La estructura de dependencia entre los paquetes debe ser un grafo dirigido acíclico (DAG). Esto es, no debe

haber ciclos en la estructura de dependenciaRobert C. Martin

Paquetedependiente

Paquete

8.7 El principio de dependencia acíclica (i)

126




251



Mi Aplicación

Ventana demensaje

Ventana detarea

MisTareas

Base deDatos

TareaVentanas

MisDiálogos

Diagrama de paquetes sin ciclos

8.7 El principio de dependencia acíclica (ii)

252



Mi Aplicación

Ventana demensaje

Ventana detarea

MisTareas

Base deDatos

TareaVentanas

MisDiálogos

Diagrama de paquetes con ciclos

8.7 El principio de dependencia acíclica (iii)

127




253



MisDiálogos MiAplicación

MisDiálogos MiAplicación

Antes

Después

X Y

YX ServidorX

Eliminación del ciclo con el principio de inversión de la dependencia

8.7 El principio de dependencia acíclica (iv)

254



Las dependencias entre paquetes en un diseño debe hacerse buscando la dirección de la estabilidad de los paquetes. Un paquete debe depender sólo de

los paquetes que son más estables que élRobert C. Martin

Las dependencias entre paquetes en un diseño debe hacerse buscando la dirección de la estabilidad de los paquetes. Un paquete debe depender sólo de

los paquetes que son más estables que élRobert C. Martin

8.8 El principio de las dependencias estables (i)

Métricas de EstabilidadAcoplamientos Aferentes (Ca): Se define como el número de clases fuera del paquete que dependen de las clases contenidas en el paquete

Acoplamientos Eferentes (Ce): Se define como el número de clases dentro del paquete que dependen de clases externas al paquete

Inestabilidad (I): Esta métrica está comprendida en el intervalo [0, 1], de forma que I=0 indica un paquete completamente estable, y por el contrario I=1 indica un paquete completamente inestable. La inestabilidad se define mediante la siguiente relación

Ca + CeCe

I =

128




255



12

AB

C

D E

I J

H

FG Ca = 4

Ce = 3I = 3/7

8.8 El principio de las dependencias estables (ii)

256



Los paquetes que son estables al máximo deben ser abstractos al máximo. Los paquetes inestables deben ser concretos. La abstracción de un paquete

debe ser proporcional a su estabilidadRobert C. Martin

Los paquetes que son estables al máximo deben ser abstractos al máximo. Los paquetes inestables deben ser concretos. La abstracción de un paquete

debe ser proporcional a su estabilidadRobert C. Martin

Clases TotalesClases Abstractas

A =

Métrica de Abstracción de un Paquete

8.9 El principio de las abstracciones estables (i)

129




257



1

1

Ab s

tra c

ción

Inestabilidad

(1, 0)

(0, 1)

Secuenciaprincipal

1

1

Abs

trac

ción

(1, 0)

Inestabilidad

(0, 1)

Secuenciaprincipal

(0, 0) Zona

de exclusión

(1, 1) Zonade exclusión

8.9 El principio de las abstracciones estables (ii)

258



9. Introducción a los patrones de diseño

130




259



9.1 Concepto intuitivo de patrón (i) ¿Qué es un patrón software?

Un patrón es un “dechado que sirve de muestra para sacar otra cosa igual” [RAE, 2001]

Elemento reutilizable de experiencia y conocimiento

Aplicación en los ambientes de desarrollo de software,especialmente en la OO

Dentro de la OO, los patrones se utilizan para expresar la experiencia acumulada durante, aproximadamente, los 30 años de existencia de esta disciplina, con un especial énfasis en el DOO

260



9.1 Concepto intuitivo de patrón (ii)

Los patrones representan soluciones a problemas que aparecen en el desarrollo del software dentro de un contextoLos patrones más difundidos son los patrones de diseño

representado físicamente por >Libro Ejemplar1 *

representado físicamente por >Definición de

EntidadRepresentación

de Entidad1 *

“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y entonces se describe el núcleo de la solución a dicho problema de tal forma que se puede usar esta solución un millón de veces sin hacerlo dos veces de la misma

forma” [Alexander, 1979]

“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y entonces se describe el núcleo de la solución a dicho problema de tal forma que se puede usar esta solución un millón de veces sin hacerlo dos veces de la misma

forma” [Alexander, 1979]

131




261



9.2 Origen de los patrones (i)

El concepto de patrón dentro de la OO se difunde gracias al trabajo de Erich Gamma, Richard Helm, Ralph Jonhson y John Vlissides [Gamma et al., 1993], [Gamma et al., 1995]

Conocidos popularmente como la Banda de los Cuatro o GoF (Gangof Four)Especialmente con la publicación de su libro Design Patterns: Elements of Reusable Object-Oriented Software [Gamma et al., 1995]

El origen de la teoría de patrones está en los trabajos del arquitecto Christopher Alexander

262



9.2 Origen de los patrones (ii)

Terminología- Patrón: Una solución de un problema en un contexto- Lenguaje de Patrones: Conjunto de patrones utilizados para

solucionar un problema en un contextoPropósito

- Reutilización efectiva- Diseminación de soluciones

- -

Christopher Alexander (arquitecto)

- Notes on the Synthesis of Form [Alexander, 1964]- A Pattern Language [Alexander et al., 1977]- The Timeless Way of Building [Alexander, 1979]

• La calidad, la puerta y la forma

132




263



9.2 Origen de los patrones (iii)Evolución histórica dentro de la Orientación a Objetos

- Workshop en OOPSLA’87 [Beck y Cunningham, 1987]

- Advanced C++ Programming Styles and Idioms [Coplien, 1992]

- The Hillside Group (1993)

- Conferencias PLoP - Pattern Languages of Program Design (1994)

- Design Patterns: Elements of Reusable Object-OrientedSoftware [Gamma et al., 1995]

264



9.3 Definición de patrón softwareUn patrón es una descripción en un formato fijo de cómo solucionar un cierto tipo de problemas [Reenskaug et al., 1996]Cada patrón es una regla constituida por tres partes, la cual expresa una relación entre un cierto contexto, un cierto sistema de fuerzas que ocurren repetidamente en ese contexto, y una cierta configuración software que permite a estas fuerzas resolverse así mismas [Coplien, 2003]Un patrón es una unidad de información instructiva con nombre que captura la estructura esencial y la comprensión de una familia de soluciones exitosas probadas para un problema recurrente que ocurre dentro de un cierto contexto y de un sistema de fuerzas [Appleton, 2000]Un patrón de diseño es una descripción de clases y objetos comunicándose entre sí, adaptada para resolver un problema de diseño general en un contexto particular [Gamma et al., 1995]Un patrón de diseño es una abstracción de un problema de diseño general, que ocurre recurrentemente en contextos específicos no arbitrarios [Aklecha, 1999]

133




265



9.4 Características de un patrónUn buen patrón debe cumplir las siguientes premisas

Debe solucionar un problema: Captura soluciones, no sólo principios abstractos o estrategiasSon conceptos probados: Captura soluciones probadas no especulacionesLa solución no es obvia: Los mejores patrones generan una solución para un problema indirectamente, una aproximación necesaria para los problemas de diseño más complejosDescribe una relación: Describe sistemas, estructuras o mecanismos más profundosDebe tener un componente humano importante: Recurre explícitamente a la estética y a la utilidad

266



9.5 Descripción de un patrón (i)Elementos esenciales de un patrón

En el libro de GoF [Gamma et al., 1995]NombreProblemaSoluciónConsecuencias

“Un patrón es una regla que establece una relaciónentre un contexto, un sistema de fuerzas que aparecenen el contexto y una configuración” [Alexander, 1979]

134




267



9.5 Descripción de un patrón (ii)

Los patrones se describen utilizando formatos consistentes

Plantilla dividida en secciones, que ofrece uniformidadExisten diferentes formatos de descripción de patrones

Formato de Alexander [Alexander, 1979]Formato canónico [Buschmann et al., 1996]Formato del GoF [Gamma et al., 1995]

268



9.5 Descripción de un patrón (iii)Formato del GoF [Gamma et al., 1995]

Nombre del patrón y clasificación

Propósito

También conocido como

Motivación

Aplicabilidad

Estructura

Participantes

Colaboraciones

Consecuencias

Implementación

Código de ejemplo

Usos conocidos

Patrones relacionados

135




269



9.6 Tipos de patrones softwareLos patrones de DOO son los más conocidosExisten otros tipos de patrones

De análisis [Fowler, 1996]Pedagógicos [Lilly, 1996]De organizaciónPatrones enviados a las diferentes ediciones de las conferencias PLoP

270



9.7 Clasificación de los patrones de diseño (i)POSA [Buschmann et al., 1996]

Categoría del patrónRelacionado con la principales fases y actividades en el desarrollo del software

Categoría del problemaLos diferentes tipos de problemas que pueden surgir en el desarrollo de sistemas software

GoF [Gamma et al., 1995]Propósito

Refleja qué hace el patrón

ÁmbitoSi el patrón se aplica a clases o a objetos

136




271



9.7 Clasificación de los patrones de diseño (ii)POSA – Categorías de patrones

Patrones arquitectónicosPara expresar el esquema de una organización estructural fundamental para los sistemas softwareSon plantillas para arquitecturas software concretasProporcionan un conjunto de subsistemas predefinidos, especifican sus responsabilidades e incluye reglas y recomendaciones para organizar las relaciones entre los subsistemasLa selección de un patrón arquitectónico es una decisión de diseño fundamental cuando se desarrolla un sistema softwareEjemplos: Modelo-Vista-Controlador, Capas (Layers), Broker, Pipes and Filter

Patrones de diseñoDe menor escala que los patrones arquitectónicos y sin efectos sobre la estructura fundamental de los sistemas softwareProporcionan un esquema para refinar los subsistemas o componentes de un sistema software o las relaciones entre ellosDescriben un estructura frecuente de componentes que se comunican y que resuelven un problema general de diseño en un contexto particularEjemplos: Observer, Publisher-Subscriber

IdiomasSon patrones de bajo nivel específicos de lenguajes de programaciónDescriben cómo implementar aspectos particulares de componentes o las relaciones entre ellos utilizando las características de un lenguaje dadoEjemplo: while (*destino++ = *src++);

272



9.7 Clasificación de los patrones de diseño (iii)GoF – Clasificación de patrones

Ámbito de clasePatrones de Creación – Cómo instanciar objetos ocultando la parte específica del proceso de creación

Factory MethodPatrones Estructurales – Cómo utilizar la herencia para componer protocolos o código

AdapterPatrones de comportamiento – Cómo cooperan las clases con sus subclases para ajustarse a su semántica

Template MethodÁmbito de objeto

Patrones de creación – Cómo se crean conjuntos de objetosAbstract Factory

Patrones estructurales – Cómo juntar objetos para hacerse cargo de una funcionalidad nuevaProxy, Flyweight

Patrones de comportamiento – Cómo un grupo de objetos “equivalentes” (peer) coperan para llevar a cabo una tarea que un objeto por sí solo no puede llevar a cabo

Mediator, Chain of Responsibility, Observer, Model-View, StrategyÁmbito de composición

Patrones de creación – Cómo crear una estructura recursiva de objetosBuilder

Patrones estructurales – Cómo crear estructuras recursivas de objetosComposite, Wrapper

Patrones de comportamiento – El comportamiento de estructuras recursivas de objetosIterator

137




273



10. Algunos patrones de diseño

274



MVC (i)

El patrón MVC es un patrón arquitectónico [Buschman et al., 1996]Pertenece a la categoría de los patrones para sistemas interactivosSe encuentra en muchos sistemas interactivos y frameworks de aplicación para software con interfaces gráficas (MacApp, ET++, bibliotecas de Smalltalk, MFC)

138




275



MVC (ii)Problema

Propensión que tienen las interfaces de usuario para cambiar, al extender la funcionalidad de una aplicación o al portarla a un entorno gráfico diferenteConstruir un sistema flexible es caro y propenso a los errores si la interfaz de usuario está altamente entremezclada con el núcleo funcional

Fuerzas que intervienenLa misma información es presentada de maneras diferentes en distintas ventanasLa presentación y el comportamiento de una aplicación deben representar los cambios en los datos inmediatamenteLos cambios en la interfaz de usuario deben ser sencillos e incluso factibles en tiempo de ejecuciónSoportar diferentes estándares de interfaces gráficas o portar la interfaz de usuario no debe afectar al código del núcleo de la aplicación

276



MVC (iii)

SoluciónEl patrón MVC divide la aplicación en tres áreas: proceso, entrada y salida

El componente de modelo encapsula los datos y la funcionalidad central

Es independiente de la entrada y la salida

Los componentes de vista presentan la información al usuarioUna vista obtiene datos del modelo, pudiendo haber múltiples vistas del modelo

Los controladores reciben la entrada, normalmente eventos que son trasladados para servir las peticiones del modelo o de la vista

El usuario interactúa con el sistema sólo a través de los controladores

139




277



MVC (iv)Clase Modelo Responsabilidades

• Ofrece la funcionalidad central de la aplicación

• Registrar las vistas y controladores dependientes

• Notificar a los componentes dependientes sobre cambio en los datos

Colaboradores • Vista • Controlador

Clase Vista Responsabilidades

• Crear e iniciar su controlador asociado

• Mostrar la información al usuario

• Implementar el método actualizar()

• Recuperar datos del modelo

Colaboradores • Controlador • Modelo

278



MVC (v)

Clase Controlador Responsabilidades

• Aceptar los eventos de entrada del usuario

• Traducir los eventos en peticiones de servicio

• Implementar el método actualizar() si se requiere

• Recuperar datos del modelo

Colaboradores • Vista • Modelo

140




279



MVC (vi)

iniciar(Modelo)hacerControlador()activar()mostrar()

Vista

iniciar(Modelo, Vista)manejarEvento()

Controlador

actualizar()

Observador

conectar(Observador)desconectar(Observador)notificar()conseguirDatos()servicio()

datos

Modelo

11

1..*

1

1

280



MVC (vii)Ventajas

Múltiples vistas del mismo modeloVistas sincronizadasCambios de vistas y controles en tiempo de ejecuciónCambio del aspecto externo de las aplicacionesBase potencial para construir un framework

InconvenientesSe incrementa la complejidadNúmero de actualizaciones potencialmente altoÍntima conexión entre la vista y el controladorAlto acoplamiento de las vistas y los controladores con respecto al modeloAcceso ineficiente a los datos desde la vistaCambio inevitable de las vistas y controladores cuando se porte a otras plataformas

141




281



Fabrica abstracta (i)Patrón Fabrica abstracta (Abstract Factory) – Patrón de creación de objetos [Gamma et al., 1995]

Los patrones de creación se utilizan para construir una abstracción sobre el proceso de instanciación, introduciendo una gran dosis de flexibilidad en todos los aspectos que involucren creación de objetos

También conocido como KitOfrece una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas

282



Fabrica abstracta (ii)

AplicabilidadUn sistema debe ser independiente de cómo se creen, se compongan y se representen sus objetosUn sistema debe ser configurado con un producto de múltiples familias de productosUna serie de productos relacionados están diseñados para usarse conjuntamente, queriéndose reforzar esta característicaSe quiere distribuir una biblioteca de clases que implementa un determinado producto, queriéndose revelar sólo sus interfaces, no sus implementaciones

142




283



Fabrica abstracta (iii)Solución

<<estereotipo>>CLIENTE

+CrearProducto():ProductoAbstracto{abstracto}

<<estereotipo>>FactoríaAbstracta

{abstracta} <<estereotipo>>ProductoAbstracto

{abstracta}

+CrearProducto():ProductoAbstracto

<<estereotipo>>FactoríaConcreta

#Producto()

<<estereotipo>>Producto

284



Fabrica abstracta (iv)

+ CrearDispositivo(): *Dispositivo {abstracto}+ CrearBoton(): *Boton {abstracto}+ CrearFormulario(): *Formulario {abstracto}+ ...

FactoriaControles{abstracta}

+ CrearDispositivo(): *Dispositivo+ CrearBoton(): *Boton+ CrearFormulario(): *Formulario+ ...

FactoriaControlesGráfico

+ CrearDispositivo(): *Dispositivo+ CrearBoton(): *Boton+ CrearFormulario(): *Formulario+ ...

FactoriaControlesTexto

+ Botón()+ DibujaBotón()

char *msgint x1,y1,x2,y2

Botón{abstracta}

BotónTexto BotónGráfico

+ Inicia()

Dispositivo{abstracta}

DispositivoTexto DispositivoGráfico

Cliente

143




285



Fabrica abstracta (v)Ventajas

Aísla los clientes de las implementaciones, ya que sólo usan la interfazLas dependencias se aíslan en las fabricas concretasFacilita el cambio de familias de productos, ya que la clase de familia concreta sólo aparece una vez y es fácil cambiarlaFavorece la consistencia entre productos, ya que favorece que sólo se use una familia de productos a la vez

InconvenienteEl soporte de nuevos productos se complica porque afecta a la interfaz de la fábrica abstracta y por consiguiente de todas sus subclases

286



Singleton (Único) (i)

Patrón Único (Singleton) – Patrón de creación de objetos [Gamma et al., 1995]Garantiza que una clase sólo tenga un instancia

Proporciona un punto de acceso global a ella

144




287



Singleton (Único) (ii)Problema

Es importante que algunas clases tengan exactamente una instancia¿Cómo se puede asegurar que una clase tenga una única instancia y que ésta sea fácilmente accesible?

Una variable global hace accesible a un objeto, pero no impide crear múltiples instancias

Una mejor solución es hacer que sea la propia clase la responsable de su única instancia

La clase puede garantizar que no se puede crear ninguna otra instanciaInterceptará las peticiones para crear nuevos objetosAdemás, debe proporcionar un modo de acceder a la instancia

288



Singleton (Único) (iii)Aplicabilidad

Se usará este patrón cuandoDeba haber exactamente una instancia de una clase, y ésta debe ser accesible a los clientes desde un punto de acceso conocidoLa única instancia debería ser extensible mediante herencia, y los clientes deberían ser capaces de usar una instancia extendida sin modificar su código

145




289



Singleton (Único) (iv)Solución

Se define una operación Instancia que permite que los clientes accedan a su única instancia

Es una operación de clase

Puede ser responsable de crear si única instanciaLos clientes acceden a la instancia de un Singleton sólo a través de la operación Instancia

+Instancia()+OperacionDelSingleton()#ObtenerDatosDelSingleton()

-unicaInstancia-datosDelSingleton

Singleton

return unicaInstancia

290



Singleton (Único) (v)Ventajas

Acceso controlado a la única instanciaLa clase Singleton encapsula su única instancia, así puede tener un control estricto sobre cómo y cuándo acceden a ella los clientes

Espacio de nombres reducidoEvita contaminar el espacio de nombres con variables globales que almacenen las instancias

Permite el refinamiento de operaciones y la representaciónSe puede crear una subclase de la clase Singleton, y es fácil configurar una aplicación con una instancia de la clase extendida, incluso en tiempo de ejecución

Permite un número variable de instanciasEs fácil permitir más de una instancia de la clase Singleton

Más flexible que las operaciones de claseLas funciones de clase dificultan cambiar un diseño para permitir más de una instancia, además, las funciones estáticas en C++ no son virtuales, por lo que las subclases no las podrían redefinir polimórficamente

146




291



Singleton (Único) (vi)

Detalles de implementación – Garantizar una única instancia

Una forma de asegurar una única instancia es ocultar la operación que crea la instancia tras una operación de clase que garantice que sólo se crea una única instancia

Esta operación tiene acceso a la variable que contiene la instancia y se asegura de que la variable está inicializada con dicha instancia antes de devolver su valor

Este enfoque garantiza que un Singleton se cree e inicialice antes de su primer uso

292



Singleton (Único) (vii)Detalles de implementación – Garantizar una única instancia

class Singleton {public:

static Singleton* Instancia();protected:

Singleton();private:

static Singleton* _instancia;};

Singleton* Singleton::_instancia=0;

Singleton* Singleton::Instancia() {if (_instancia == 0)

_instancia = new Singleton;return _instancia;

}

147




293



Singleton (Único) (viii)Detalles de implementación – Crear una subclase de Singleton

El principal problema no es definir la subclase sino instalar su única instancia de manera que los clientes la puedan usarEn esencia, la variable que hace de referencia a la única instancia debe ser inicializada con una instancia de la subclase

La técnica más sencilla es determinar qué Singleton se desea usar en la operación InstanciaOtro modo de elegir la subclase de Singleton es sacar la implementación de Instancia fuera de la clase padre y ponerla en la subclase

Este enfoque fija la elección de la clase del Singleton durante el enlazado, lo que dificulta elegir la clase del Singleton en tiempo de ejecución

Se pueden usar sentencias condicionales para determinar la subclase de una manera más flexible, pero fija el conjunto de posibles clases SingletonUn enfoque más flexible es usar un registro de objetos Singleton

En vez de que sea Instancia quien defina el conjunto de posibles clases Singleton, las clases Singleton pueden registrar su única instancia por su nombre en un registro conocido por todos

294



Singleton (Único) (ix)Detalles de implementación – Crear una subclase de Singleton

class Singleton {public:static void Registrar(const char* nombre, Singleton*);static Singleton* Instancia();

protected:static Singleton* Buscar(const char* nombre);

private:static Singleton* _instancia;static List<ParNombreSingleton>* _registro;

};

148




295



Singleton (Único) (x)Detalles de implementación – Crear una subclase de Singleton

Registrar() registra la instancia del Singleton con el nombre especificadoPara mantener el registro simple, se tiene una lista de objetos ParNombreSingleton

Cada ParNombreSingleton hacer corresponder un nombre con un Singleton

Buscar() busca un Singleton dado su nombre

296



Singleton (Único) (xi)Detalles de implementación – Crear una subclase de Singleton

Singleton* Singleton::Instancia () {if (_instancia == 0) {

const char * nombreSingleton = getenv(“SINGLETON”);// proporcionada por el usuario o el entorno

_instancia = Buscar (nombreSingleton);// Retorna 0 si no existe tal Singleton

}return _instancia;

}

149




297



Singleton (Único) (xii)Detalles de implementación – Crear una subclase de Singleton

¿Dónde se registran las instancias de las clases Singleton?

Una posibilidad es en su constructor

MiSingleton::MiSingleton {// …Singleton::Registrar(“MiSingleton”, this);

}

Pero, el constructor no será llamado a menos que alguien cree una instancia de la clase

Estos reproduce el problema que se está tratando de resolver

Se puede evitar definiendo una instancia estática de MiSingleton (static MiSingleton elSingleton;) en el fichero que contiene la implementación de MiSingleton

298



Puente (i)

Patrón Puente (Bridge) – Patrón estructural [Gamma et al., 1995]

Los patrones estructurales expresan cómo las clases y objetos se componen para formar estructuras mayores

También conocido como Handle/Body o EnvelopeDesacopla una abstracción de su implementación para que ambas puedan variar independientemente

150




299



Puente (ii)Problema

Cuando una abstracción puede tener una de varias implementaciones, la forma usual de tratarlo es con herencia

Una clase abstracta define la interfaz de la abstracción, mientras que las subclases concretas la implementan de diferentes maneras

Esta aproximación no es flexibleLa herencia enlaza una implementación a la abstracción de forma permanente, lo que dificulta la modificación, extensión y reutilización de las abstracciones y de las implementaciones independientemente

Push(T)Pop( ) : TTop( ) : TEstáVacía( ):bool

PilaT

PilaArray

T

PilaLista

T

PilaFichero

T

300



Puente (iii)

AplicabilidadSi se quiere evitar un enlace permanente entre una abstracción y su implementaciónTanto la abstracción como la implementación se quiere que sean extensibles por derivaciónSe quiere aislar a los clientes de cambios en la implementaciónSe quiere compartir una implementación entre múltiples entidades

151




301



Puente (iv)Solución

Operación( )

Abstracción

AbstracciónRefinada

ImpOperación( )

Implementadorimpl

ImplementadorConcretoA ImplementadorConcretoB

impl->ImpOperación()

Cliente

302



Puente (v)

Puente

Push(T)Pop( ) : TTop( ) : TEstáVacía( ):bool

PilaT

Vaciar()

PilaExtendidaT

while ( ! EstáVacía ( ) ) Pop()

impPush(T)impPop( ) : TimpTop( ) : TimpEstáVacía( ):bool

ImpPilaT

impl

ImpPilaArray ImpPilaLista ImpPilaFicheroT T T

152




303



Puente (vi)

ConsecuenciasDesacopla la interfaz y la implementación, pudiendo configurarse o cambiarse en tiempo de ejecuciónFavorece la división en niveles de un sistemaAmbas jerarquías pueden extenderse por herencia independientementeOculta a los clientes los detalles de implementación

304



Mediador (i)

Patrón Mediador (Mediator) – Patrón de comportamiento [Gamma et al., 1995]

Los patrones de comportamiento están relacionados con los algoritmos y la asignación de responsabilidades. No describen tan sólo patrones de objetos y clases, sino patrones de comunicación entre ellos

Su objetivo es definir un objeto que encapsule como interactúan un conjunto de objetos, evitando que tengan que conocerse entre ellos y permitiendo cambiar la interacción de forma independiente

153




305



Mediador (ii)Problema (i)

Que un objeto encapsule todo su comportamiento suele ser adecuado, salvo en aquellos casos que suponga un número excesivo de enlaces

A B

D

E C

A B

D

E CMediator

306



Mediador (iii)Problema (ii)

Un cuadro de diálogo para abrir un archivo tiene muchos objetos interdependientes: se evita derivar cada uno

154




307



Mediador (iv)

AplicabilidadCuando un conjunto de objetos se comunica de una forma bien definida pero compleja (con interdependencias complicadas)Cuando reutilizar una entidad sea difícil por tener referencias a muchos objetos por comunicarse con ellosCuando un comportamiento distribuido entre varias clases debe ser adaptado sin tener que derivar muchas clases

308



Mediador (v)Solución

Mediador

MediadorConcreto

Colega

ColegaConcreto1 ColegaConcreto2

mediador

155




309



Mediador (vi)

DiálogoAbrirArchivo

mediador

Cambiado( )ControlMostrar( )

CrearControles( )CambioEnControl(Control)

Diálogo

GetSelección():CadenaLista

SetImagen(Archivo: Cadena)Visor

lista

visor

mediador->CambioEnControl (this)

310



Mediador (vii)

unCliente

Mostrar( )

unDiálogoAbrirArchivo unaLista

CambioEnControl(this)

img=GetSelección( )

unVisor

SetImagen(img)

156




311



Mediador (viii)Ventajas

Evita derivar nuevas clases de colegasPara cambiar la conducta sólo hay que derivar un nuevo mediador

Desacopla colegas, permitiendo que cambien independientementeSimplifica los protocolos de los objetos, al cambiar las asociaciones m:n por 1:n, más sencillas de entender, mantener y ampliarAbstrae la cooperación entre los objetos y la encapsula en el mediador, siendo más fácil entender cómo funciona el sistema

InconvenienteCentraliza el control en el mediador, que es un objeto complejo y difícil de entender

312



11. Referencias (i)[Abbott, 1983] Abbott, R. J. “Program Design by Informal English Descriptions”.

Communications of the ACM, 26(11):882-894. November 1983[Aklecha, 1999] Aklecha, V. “Object-Oriented Frameworks Using C++ and CORBA Gold

Book”. Coriolis Technology Press, 1999[Alexander, 1964] Alexander, C. “Notes on the Synthesis of Form”. Harvard University

Press, 1964[Alexander, 1979] Alexander, C. “The Timeless Way of Building”. The Oxford University

Press, 1979[Alexander et al., 1977] Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M.,

Fiksdahl-King, I., Angel, S. “A Pattern Language”. Oxford University Press, 1977[Ancona et al., 1992] Ancona, D., Astesiano, E., Zucca, E. “Towards a Classification of

Inheritance Relations”. Technical Report, Dipartimento di Informatica e Scienzedell’Informazione, Genova. 1992

[Appleton, 2000] Appleton, B. “Patterns and Software: Essential Concepts and Terminology”. http://www.cmcrossroads.com/bradapp/docs/patterns-intro.html [Última vez visitado, 9-3-2005]. February 2000

[Beck y Cunningham, 1987] Beck, K., Cunningham, W. “Using a Pattern Language for Programming”. In Addendum to the Proceedings of OOPSLA’87. 1987

[Beck y Cunningham, 1989] Beck, K., Cunningham, W. “A Laboratory for Teaching Object-Oriented Thinking”. In Proceedings of the 1989 OOPSLA - Conference proceedings on Object-Oriented Programming Systems, Languages and Applications (October 2 - 6, 1989, New Orleans, LA USA); Reprinted in Sigplan Notices, 24(10):1-6. 1989

157




313



11. Referencias (ii)[Booch, 1994] Booch, G. “Object Oriented Analysis and Design with Applications”. 2nd Edition.

The Benjamin/Cummings Publishing Company, 1994[Budd, 1991] Budd, T. “An Introduction to Object-Oriented Programming”. Addison-Wesley,

1991[Buschmann et al., 1996] Buschmann, F., Meunier, R., Rohnert, H,, Sommerlad, P.,

Stal, M. “Pattern Oriented Software Architecture: A System of Patterns”. John Wiley & Sons, 1996

[Coplien, 1992] Coplien, J. O. “Advanced C++ Programming Styles and Idioms”, Addison-Wesley, 1992

[Coplien, 2003] Coplien, J. O. “A Pattern Definition - Software Patterns”. http://hillside.net/patterns/definition.html [Última vez visitado, 9-3-2005]. 2003

[Crespo, 2000] Crespo González-Carvajal, Y. “Incremento del Potencial de Reutilización del Software mediante Refactorización”. Tesis Doctoral. Universidad de Valladolid. 2000

[Fowler, 1996] Fowler, M. “Analysis Patterns: Reusable Object Models”. Object Technology Series. Addison-Wesley, 1996

[Firesmith et al., 1998] Firesmith, D., Henderson-Sellers, B., Graham, I. “OPEN Modeling Language (OML) Reference Manual”. Cambridge University Press, 1998

[Gamma et al., 1993] Gamma, E., Helm, R., Johnson, R., Vlissides, J. “Design Patterns: Abstraction and Reuse of Object-Oriented Design”. In Proceedings of the 7th European Conference in Object Oriented Programming – ECOOP’93. Nierstrasz, O. M. (Ed.). Pages 406-431. Springer Verlag, 1993

314



11. Referencias (iii)[Gamma et al., 1995] Gamma, E., Helm, R., Johnson, R., Vlissides, J. “Design Patterns.

Elements of Reusable Object-Oriented Software”. Addison-Wesley, 1995[Graham, 1994] Graham, I. “Object-Oriented Methods”. 2nd Edition. Addison-Wesley, 1994[Graham et al., 1997] Graham, I, Bischof, J., Henderson-Sellers, B. “Associations

Considered a Bad Thing”. Journal of Object-Oriented Programming (JOOP), 9(9):41-48. February 1997

[Jacobson, 1987] Jacobson, I. “Object Oriented Development in an Industrial Environment”. In Proceedings of the 1987 OOPSLA - Conference proceedings on Object-Oriented Programming Systems, Languages and Applications. (October 4-8, 1987, Orlando, FL USA). Pages 183-191. ACM Press, 1987

[Jacobson et al., 1992] Jacobson, I., Christerson, M., Jonsson, P., Övergaad, G.“Object Oriented Software Engineering: A Use Case Driven Approach”. Addison-Wesley, 1992. Revised 4th printing, 1993

[Joyanes, 1998] Joyanes Aguilar, L. “Programación Orientada a Objetos”. 2ª Edición. McGraw-Hill, 1998

[Halbert y O’Brien, 1987] Halbert, D., O’Brien, P. “Using Types and Inheritance in Object-Oriented Programs”. IEEE Software, 71-79. 1987

[Larman, 1999] Larman, C. “UML y Patrones. Introducción al Análisis y Diseño Orientado a Objetos”. Pearson, 1999

[Larman, 2002] Larman, C. “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process”. 2nd Ed. Prentice Hall, 2002

158




315



[Lieberherr et al., 1988] Lieberherr, K., Holland, I., Riel, A. “Object-Oriented Programming: An Objective Sense of Style”. In OOPSLA 88 Conference Proceedigns. ACM Press, 1988

[Lilly, 1996] Lilly, S. “Patterns for Pedagogy”. Object Magazine, 5(8):93-96. January, 1996[Liskov, 1987] Liskov, B. “Data Abstraction and Hierarchy”. In Addedum to Proceedings of

OOPSLA’87. Pages 17-35. ACM Press, 1987[Marqués, 1995] Marqués Corral, J. M. “Jerarquías de Herencia en el Diseño de Software

Orientado al Objeto”. Tesis Doctoral. Facultad de Ciencias, Universidad de Valladolid, 1995

[Meyer, 1997] Meyer, B. “Object Oriented Software Construction”. 2nd Edition. Prentice Hall, 1997

[Oestereich, 1999] Oestereich, B. “Developing Software with UML. Object-Oriented Analysis and Design in Practice”. Object Technology Series. Addison-Wesley, 1999

[OMG, 2003] OMG. “OMG Unified Modeling Language Specification Version 1.5”. Object Management Group Inc. Document formal/03-03-01. March 2003. http://www.omg.org/uml[Última vez visitado, 9-3-2005]

[RAE, 2001] Real Academia Española “Diccionario de Real Academia”. Vigésimo segunda edición. http://www.rae.es. [Última vez visitado, 9-3-2005]. 2001

[Reenskaug et al., 1996] Reenskaug, T., Wold, P., Lehne, O. A. “Working with Objects. The OOram Software Engineering Method”. Manning Publications Co./Prentice Hall, 1996

11. Referencias (iv)

316



11. Referencias (v)[Rumbaugh et al., 1991] Rumbaugh, J., Blaha, M., Premerlani, W., Eddy, F.,

Lorensen, W. “Object-Oriented Modeling and Design”. Prentice-Hall, 1991[Sakkinen, 1989] Sakkinen, M. “Disciplined Inheritance”. In Proceedings of ECOOP’89.

Cook, S. (Ed.). Pages 39-56. Cambridge University Press, 1989[Stroustrup, 1997] Stroustrup, B. “The C++ Programming Language”. 3rd Edition, Addison

Wesley, 1997[Wirfs-Brock et al., 1990] Wirfs-Brock, R, Wilkerson, B., Wiener, L. “Designing Object-

Oriented Software”. Prentice-Hall, 1990

159




317



12. Lecturas complementarias (i)Alexander, C. “The Origins of Pattern Theory. The Future of the Theory, and the Generation of

a Living World”. IEEE Software, 16(5):71-82. September/October 1999Presentación de la teoría de los patrones de la mano de su creador

Beck, K., Cunningham, W. “A Laboratory for Teaching Object-Oriented Thinking”. In Proceedings of the 1989 OOPSLA - Conference proceedings on Object-Oriented Programming Systems, Languages and Applications (October 2 - 6, 1989, New Orleans, LA USA); Reprinted in Sigplan Notices, 24(10):1-6. 1989Artículo que introduce las tarjetas de clase o tarjetas CRC

Binder, R. “Verifying Class Associations”. Object Magazine, 7(9):18-20. November 1997Comenta los fallos más frecuentes en el diseño de asociaciones, así como comprobar su corrección

Cardelli, L., Wegner, P. “On Understanding Types, Data Abstraction and Polymorphism”. Computing Surveys, 17(4):471-523. December 1985Artículo clásico de la teoría de tipos, donde se explica y se clasifica el polimorfismo dentro de los lenguajes de programación

Coad, P. “Object-Oriented Patterns”. Communications of the ACM, 35(9):152-159. September1992Búsqueda de patrones en el análisis y en el diseño orientado a objetos

García Peñalvo, F. J. “Patrones. De Alexander a la Tecnología de Objetos”. Revista Profesional para Programadores (RPP), Editorial América-Ibérica, V(10):44-52. Noviembre, 1998. (También disponible en http://zarza.fis.usal.es/~fgarcia/doc/patrones1.pdf)Artículo introductorio sobre los patrones software

318



12. Lecturas complementarias (ii)García Peñalvo, F. J., Pardo Aguilar, C. “El Principio Abierto/Cerrado”. Revista Profesional

para Programadores (RPP), Editorial América-Ibérica, V(6):52-56. Junio, 1998Artículo en el que se explica el principio de diseño abierto/cerrado, apoyándose en un ejemplo en C++

García Peñalvo, F. J., Marqués Corral, J. M. “El Principio de Sustitución de Liskov”. Revista Profesional para Programadores (RPP), Editorial América-Ibérica, V(7):40-44. Julio, 1998Artículo que explica el principio de sustitución de Liskov, ilustrándolo con un ejemplo en C++

García, F. J., Marqués, J. M., Maudes, J. M. “Análisis y Diseño Orientado al Objeto para Reutilización”. Technical Report (TR-GIRO-01-97V2.1.1), Universidad de Valladolid (España). Octubre, 1997Informe técnico sobre las actividades a llevar a cabo en el desarrollo de elementos reutilizables bajo el paradigma objetual

Graham, I., Bischof, J., Henderson-Sellers, B. “Associations Considered a Bad Thing”. Journal of Object-Oriented Programming (JOOP), 9(9):41-48. February 1997Artículo crítico con las asociaciones bidireccionales tal y como se presentan en UML 1.x o en OMT. Se aboga por modelarlas mediante pares de asociciones unidireccionales (mappings)

Henderson-Sellers, B. “OPEN Relationships- Compositions and Containments”. Journal ofObject-Oriented Programming (JOOP), 10(7):51-55,72. November/December 1997Artículo que describe las relaciones de meronimia desde una perspectiva diferente a como lo hace UML

160




319



12. Lecturas complementarias (iii)López Tallón, A. “Patrones de Diseño. Reutilización de Ideas”. Revista Profesional para

Programadores (RPP), Editorial América-Ibérica, V(8):54-58. Septiembre, 1998Repasa algunos patrones definidos en el libro de GoF [Gamma et al., 1995], en concreto los patrones Observer, Composite y Visitor

Meyer, B. “Construcción de Software Orientado a Objetos”. 2ª Edición. Prentice Hall, 1999Son muchos los capítulos de este libro cuya lectura puede complementar la exposición realizada en el tema. No obstante, se recomienda encarecidamente la lectura de su capítulo 24, Utilizando bien la herencia, donde se presenta una taxonomía de la herencia en doce categorías

Parsons, J., Wand, Y. “Choosing Classes in Conceptual Modeling”. Communications of theACM, 40(6):63-69. June 1997Artículo en el que se trata el problema de la identificación de las clases del dominio del problema

Potel, M. “MVP: Model-View-Presenter. The Taligent Programming Model for C++ and Java”. Taligent, Inc. http://www.carfield.com.hk/document/software_design/MVP.pdf [Última vez visitado, 5-5-2003]. 1996Variación del patrón Modelo-Vista-Controlador – MVC

Riehle, D. “Working with Classes and Interfaces”. C++ Report, 12(3):14-21. March 2000Tomando las clases como elementos fundamentales en el diseño orientado a objetos, este artículo presenta cinco patrones básicos para diseñar y utilizar clases

Rising, L. “Design Patterns: Elements of Reusable Architectures”. Annual Review of Communications, Vol. 49:907-909. 1996Artículo introductorio a los patrones de diseño

320



12. Lecturas complementarias (iv)Rumbaugh, J. “Relations as Semantic Constructs in an Object-Oriented Language”. In

Proceedings of the 1987 OOPSLA - Conference proceedings on Object-Oriented Programming Systems, Languages and Applications. (October 4-8, 1987, Orlando, FL USA). ACM. Reprinted in ACM SIGPLAN 22(12):466-481. October 1987Artículo en el que Rumbaugh presenta los problemas para la implementación de las relaciones, a excepciónde la herencia, en los lenguajes orientados a objetos

Rumbaugh, J. “Depending on Collaborations: Dependencies as Contextual Associations”. Journal of Object-Oriented Programming (JOOP), 11(4):5-9. July/August 1998Artículo que aboga por la distinción de las relaciones estructurales de las relaciones procedurales

Rumbaugh, J., Jacobson, I., Booch, G. “El Lenguaje Unificado de Modelado. Manual de Referencia”. Addison-Wesley, 2000Libro para consultar cualquier duda sobre el significado de los elementos que se utilizan en los diagramas UML

Schimidt, D. C. “Introduction to Design Patterns”. Washington University, St. Louis. http://www.cs.wustl.edu/~schmidt/cs242/patterns-intro4.ps.gz [Última vez visitado, 9-3-2005]. 1998Tutorial introductorio a los patrones de diseño

Wegner, P. “Dimensions of Object-Oriented Modeling”. IEEE Computer, 25(10):12-20. October1992Artículo que establece cuáles son los fundamentos de la programación orientada a objetos

Tema 41 Programación Orientada a Objetos 3º de I.T.I.S. Departamento de Informática y Automática...

Documents

Transcript of Tema 41 Programación Orientada a Objetos 3º de I.T.I.S. Departamento de Informática y Automática...