Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO...

Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO

1

Tema 4.- TDA, polimorfismo y clases

1 La clasificación en OO.......................................................................................................2 2 Concepto de polimorfismo.................................................................................................3 3 Polimorfismo en los LOO..................................................................................................4 4 Ventajas del polimorfismo sintáctico.................................................................................6

4.1 Tipos genéricos ..........................................................................................................6 4.2 Sobrecarga..................................................................................................................7 4.3 Polimorfismo de mensajes .........................................................................................8

5 Heurísticas (normas) de diseño para aprovechar el polimorfismo.....................................9 6 Concepto de TAD ............................................................................................................10 7 Criterios para la especificación de TAD..........................................................................11

7.1 Restrictividad ...........................................................................................................12 7.2 Generalidad ..............................................................................................................14 7.3 Claridad....................................................................................................................15 7.4 Adecuación: elección de las operaciones.................................................................16

7.4.1 Tipos de operaciones en un TAD.....................................................................16 7.4.2 Elección de las operaciones .................................................................................16 7.4.3 Elección de precondiciones para las operaciones ............................................21

8 Propiedades de la representación: FA e IR......................................................................22 9 Consecuencias de diseño de la FA y el IR ........................................................................22 10 Interfaces en JAVA......................................................................................................24


2

1 La clasificación en OO * Blair (1994) propone tres posibilidades de clasificación de los objetos

en categorías:

- Conjuntos: forma de agrupar (clasificar) objetos a partir de una propiedad INTENSIONAL denotada por un predicado (consulta). La extensión del conjunto viene dada por los objetos que satisfacen el predicado (consulta). Relativamente frecuente el la BDOO. Supone una clasificación según el estado y estructura de los objetos.

- Tipos abstractos de datos: Típica clasificación funcional en base a la interface externa de los objetos.

- Clases (tipos concretos de datos): forma más restrictiva de clasificación porque define la representación y la implementación concreta.

* Desde un punto de vista teórico hay dos formas de clasificar los

objetos: 1. Deductiva: las propiedades de los objetos se deducen de la

clasificación realizada por el programador. 2. Inductiva: la clasificación se obtiene de las propiedades de los

objetos. * Todos los lenguajes OO comerciales son deductivos, es decir, los objetos adoptan las características (comportamiento y estado) que impone su clase. * Los lenguajes basados en prototipos se podrían considerar como inductivos. Todos los objetos con un comportamiento y estado idéntico se podrían considerar que forman una clase.


3

2 Concepto de polimorfismo * Es un término a su vez polimórfico que tiene (al menos) dos significados bien diferenciados:

1. POLIMORFISMO DE OBJETOS: La posibilidad de que un objeto pertenezca a más de una "clase" dentro de alguna de las categorías anteriores.

a. Un objeto pertenece a dos conjuntos: Juan es Trabajador y Estudiante por lo que se puede comportar como ambos.

b. Un objeto pertenece a dos TAD c. Un objeto pertenece a dos clases: según esto la herencia

se podría considerar una forma de polimorfismo. Un objeto de una subclase también pertenece a la superclase.

2. POLIMORFISMO SINTACTICO: posibilidad de asociar a un

mismo componente (identificador) sintáctico diferentes significados funcionales. Mecanismo de clasificación de la funcionalidad en clases sintácticas.

* El polimorfismo de objetos afecta al modo en que los objetos pertenecen a una “clase” dentro a alguna de las categorías anteriores. * El polimorfismo sintáctico afecta al modo en que se utiliza la funcionalidad (en general las llamadas a funciones y los mensajes).


4

3 Polimorfismo en los LOO

1. POLIMORFISMO DE OBJETOS Las únicas formas que se implementan en los lenguajes con clases son la herencia y la interfaces. La clasificación de objetos es deductiva, es decir, se deducen las propiedades de los objetos (estado y comportamiento) por su pertenencia a una clase. 2. POLIMORFISMO SINTACTICO. Este es el concepto que se utiliza habitualmente en los lenguajes OO cuando se habla de polimorfismo. Y es el que se considera aquí.

Significa, al menos,

1) Sobrecarga de operadores: el significado de un operador

depende del tipo de los operandos. 2) Sobrecarga de funciones: dos funciones se distinguen por el

número y tipo de sus argumentos. 3) Tipos genéricos o parametrización de tipos: un tipo genérico

podrá instanciarse para diferentes tipos. 4) Polimorfismo de mensajes o dinámico característico de los

LOO.

En todos los casos de polimorfismo sintáctico existe un CONTEXTO que determina el valor semántico exacto de cada identificador, es decir, dado un identificar sintáctico cuál es su valor semántico. Esta determinación se puede realizar:

1) En tiempo de compilación: POLIMORFISMO DE CONTEXTO PRE-ESTATICO. Se produce en los tipos genéricos (3). El Contexto es el tipo definido en la declaración de objetos.


5

2) En tiempo de encuadernación: POLIMORFISMO DE CONTEXTO ESTATICO Se produce para la sobrecarga de operadores (1) y la sobrecarga de funciones (2)

Para 1. Contexto = tipo de los operandos Para 2. Contexto = numero y tipo de los argumentos

3) En tiempo de ejecución: POLIMORFISMO DE CONTEXTO DINAMICO Se produce para el polimorfismo de mensajes (4) El Contexto es la clase a la que pertenece el objeto

La modificación del código en un tiempo obliga a repetir todo el proceso de construcción de un programa desde ese tiempo. Por ejemplo, si se modifica un tipo genérico deben recompilarse todos los programas que lo usan. Mientras que si se modifica un método sólo debe compilarse el método. Blair llama al contexto la dimensión de intepretación del comportamiento polimórfico y le asigna dos tareas:

1) Verificación de tipos: determinar si una operación es válida en un contexto 2) Ligadura: determinar la semántica (implementación) de una operación

Ambas pueden ser estáticas o dinámicas, aunque en los lenguajes reales la verificación de tipos siempre es estática.

Aunque Blair considera el polimorfismo como una forma de incorporar mecanismos de clasificación. En los lenguajes de programación simplemente se ofrecen como ventajas del lenguaje o como formulaciones teóricas ligadas a la teoría de tipos -> uso muy intuitivo.


6

4 Ventajas del polimorfismo sintáctico

4.1 Tipos genéricos * Evitar la duplicación de código para tipos que se comportan del

mismo modo y que, en general, son colecciones de objetos de otros tipos: Lista de enteros, reales,...

* Mayor facilidad de modificación del código (implementación). * La modificación de un tipo genérico implica la recompilación

de todos los programas en que se utiliza. * Necesaria la sobrecarga porque se utilizan operaciones del tipo

parámetro. En este ejemplo la operación + debe estar sobrecargada.

template <class T> class vector { T* v; int sz; public: vector (int); T& operator [] (int); T& elem (int i) {return v[i]; }; T& sumar (int i, int j) { return v[i] + v[j] } }; Uso del template: Vector <int> v1; v1.elem(7); Vector<String>v2; v2.sumar(7,8); Vector<Persona>v3; v3.sumar(7,8);


7

4.2 Sobrecarga * Facilitar la escritura de programas, asociando la misma sintaxis

a operaciones que se comportan de forma similar en distintos tipos de datos.

* Es necesaria cuando hay tipos genéricos. * No ahorra escritura de código


8

4.3 Polimorfismo de mensajes

1) Diferir (retrasar) la escritura de código, usando la especificación de una operación para anticipar el códigos de otras operaciones. La operaciones diferidas (o abstractas) se implementan en las subclases. En el siguiente ejemplo se difiere la implementación de ordena: a las subclases.

ordena: unBloqueConDosArgumentos ^ self subclassResponsibility “Responsabilidad de las subclases”

mezclaCon: unaColeccion ordenaPor: unBloqueConDosArgs “Se implementa en base a ordena:”

| otraColeccion | otraColeccion = self class new. otraColeccion = (otraColeccion addAll: self) addAll: unaColeccion. ^ otraColeccion ordena: unBloqueConDosArgs.

2) Métodos ya escritos funcionen para clases que todavía no existen, sin tener que ser modificados cuando estas se introduzcan. Se asemeja mucho a lo anterior pero en algunos lenguajes se permite incluso entre clases no relacionadas entre sí, bastará con que el mensaje exista en su protocolo. quieroSumar: unObjeto Precondiciones: unObjeto debe responder a asInteger ^self + unObjeto asInteger Desde el punto de vista del diseño la primera ventaja se explota con mayor facilidad puesto que se garantiza la existencia de las operaciones


9

diferidas. En el segundo caso hay que recurrir a precondiciones sobre las operaciones requeridas al igual que en el caso de los tipos genéricos.

5 Heurísticas (normas) de diseño para aprovechar el polimorfismo

Son escasas en la literatura, pero podemos deducirlas de sus ventajas:

1) Tratar de mantener la semántica abstracta de un identificador

sea del tipo o clase que sea. 2) No recurrir a la herencia cuando se puede utilizar con

comodidad un tipo genérico. 3) En los lenguajes en los que se puede elegir si un método estará

o no sometido a polimorfismo dinámico (métodos virtuales en C++, por ejemplo) la decisión de qué mecanismo utilizar depende de alternativas difíciles de evaluar:

- La ligadura estática es más eficiente - La ligadura dinámica es más flexible - La ligadura dinámica facilita colecciones no homogéneas - La ligadura dinámica facilita la extensión de subclases - La detección de errores es mejor en la estática - En caso de duda, si la eficiencia no es imperiosa, elegir la ligadura dinámica

4) Es difícil evaluar el polimorfismo sin tener en cuenta la herencia


10

6 Concepto de TAD ABSTRACCION DE DATOS es un conjunto de abstracciones procedimentales con interacciones entre ellas y que, supuestamente, representan todo el comportamiento asociado a una clase de objetos reconocidos en el mundo real (el habitual dominio del problema). La fuerza de la abstracción de datos reside en que el conjunto de operaciones se halla entrelazado y trabaja sobre una estructura de datos que permanece oculta en el interior de la abstracción. * La semántica de una abstracción de datos puede expresarse del siguiente modo: SIGNATURA O CABECERA SINTACTICA - Nombre de la abstracción y listado de sus operaciones DESCRIPCION - Descripción de las caractererística de la abstracción sin

realizar ninguna referencia a la implementación OPERACIONES

- Descritas en forma de abstracciones procedimentales ABSTRACCION PROCEDIMENTAL: un procedimiento se comporta como una operación simple que posee una serie de parámetros de entrada y/o de salida y que realiza una función (operación) bien definida. * La semántica de una abstracción de este tipo se puede expresar mediante la

siguiente estructura: SIGNATURA O CABECERA SINTACTICA - Nombre del procedimiento, su parámetros y tipo y el tipo

devuelto PARTE SEMANTICA - Precondiciones - Efecto (postcondición) - Parámetros modificados


11

* Niveles de un TAD. En un tipo abstracto de datos se pueden dinstinguir:

- Especificación: que constituye el nivel semántico del TAD y que determina cómo el cliente de la abstracción podrá usarla. - Representación: que indica los datos que servirán de soporte a la abstracción - Implementación de las operaciones.

Desde el punto de vista abstracto (el del cliente o usuario de la abstracción) la especificación es el elemento fundamental y es con el que se identifica el TAD. Los otros dos niveles determinan propiedades interesantes de la abstracción: eficiencia, seguridad, fiabilidad, corrección. En los lenguajes orientados a objetos los niveles de representación e implementación se concretan en las clases. El nivel de especificación también suele identificarse con la especificación de una clase, sin embargo JAVA ofrece un mecanismo para hacer especificación sin concretar la representación y la implementación: las INTERFACES.

7 Criterios para la especificación de TAD * La especificación constituye una descripción del comportamiento de una

abstracción. * Una implementación que proporciona el comportamiento especificado

SATISFACE la especificación. Habría que añadir que la implementación no debe generar efectos secundarios perniciosos (errores, por ejemplo).

* CONJUNTO ESPECIFICADO: conjunto de programas que satisfacen una

especificación. * Propiedades que deben cumplir las especificaciones:(LISKOV) del conjunto especificado: restrictividad y generalidad de la especificación: claridad de las operaciones: adecuación


12

7.1 Restrictividad * Restringir el conjunto especificado a aquellas implementaciones aceptables. * Los errores más frecuentes: - Precondiciones mal especificadas - Efecto mal especificado - Excepciones y efectos en los casos límite mal especificados * Consideremos el siguiente ejemplo: Iterardor de la clase Bag: do: unBloqueConUnArgumento Precondiciones: Efecto: ejecuta unBloqueConUnArgumento para cada elemento de self * Esta especificación admite implementaciones que no parecen muy adecuadas: 1) Se puede cambiar el cotenido de self 2) El bloque se ejecuta una sola vez para los elementos repetidos 3) El bloque se ejecuta tras ordenar los elementos de self * Una especificación más restrictiva sería la siguiente: do: unBloqueConUnArgumento Precondiciones: unBloqueConUnArgumento no debe modificar self Efecto: ejecuta unBloqueConUnArgumento para cada elemento

de self, en orden arbitrario. Por cada elemento de self el bloque se ejecuta tantas veces como esté en self.

* Otro ejemplo para un método de la clase String: contiene: unString Precondiciones: Efecto: Devuelve el lugar de self en que contiene unString como substring * No se especifican adecuadamente las situaciones extremas: - self no contiene unString - self contiene varias veces un string.


13

- admisible una implementación en la que la evaluación comience por el final de ambos strings.

- self es de menor tamaño que unString contiene: unString Precondicines: self size > 0 Efecto: Devuelve el lugar de self en que contiene, por

primera vez, unString como substring. Devuelve 0 si no lo contiene, -1 si self size < unString size. Si unString size = 0 devuelve -2.


14

7.2 Generalidad * Evitar la exclusión de implementaciones aceptables: - preferir especificaciones denotacionales (dicen lo que hacer) a

operacionales (dicen cómo hacerlo), - considerar si son necesarias cada una de las propiedades expresadas en las

precondiciones y efectos. * Método de búsqueda en una Array: La siguiente especificación es muy restrictiva porque supone una implementación concreta: buscar: unObject Precondiciones: Efecto: examina secuencialmente self hasta encontrar unObject

devolviendo el índice en que lo encuentra. 0 si no lo encuentra.

Esta especificación es más general: buscar: unObject Precondiciones: Efecto: busca unObject en self devolviendo el primer índice en

que lo encuentra. 0 si no lo encuentra.


15

7.3 Claridad * Una especificación poco clara puede conducir a malas interpretaciones. * Concisa, estructurada y con ciertas redundancias (identificadas) que permitan al

usuario y al implementador comprobar que la ha comprendido. contiene: unString Precondicines: self size > 0 Efecto: Devuelve el lugar de self en que contiene, por

primera vez, unString como substring. Devuelve 0 si no lo contiene, -1 si self size < unString size. Si unString size = 0 devuelve -2.

Por ejemplo, 'abc' contiene: 'ab' -> 1 'abc' contiene: 'abcd' -> -1 'abc' contiene: '' -> -2 * Supongamos el método incluye: unSet de las clase Set incluye: unSet

Efecto: Devuelve true si unSet es subconjunto de self, false en caso contrario

Efecto: incluye: unSet = ∀ x (x ∈ unSet and x ∈ self) Efecto: Devuelve true si unSet es subconjunto de self. False en caso contrario

Es decir, incluye: unSet = ∀ x (x ∈ unSet and x ∈ self) * La segunda y tercera especificación aclaran que unSet no es necesariamente un

subconjunto propio de self.


16

7.4 Adecuación: elección de las operaciones

7.4.1 Tipos de operaciones en un TAD * Se pueden distinguir los siguientes tipos de operaciones: 1) CONSTRUCTORES PRIMITIVOS: crean objetos del tipo sin necesitar

objetos del tipo Métodos de clase en Smalltalk o las operaciones de creación de

objetos que utilizan el NEW en C++, Pascal o JAVA. 2) CONSTRUCTORES: toman objetos del tipo como entrada y crean otros

objetos del tipo. Las operaciones aritméticas son ejemplos típicos. 3) MODIFICADORES: modifican objetos del tipo

4) OBSERVADORES: a partir de objetos del tipo devuelven objetos de otros tipos

7.4.2 Elección de las operaciones 1) No todas las operaciones son puras 2) Los tipos inmutables carecen de modificadores 3) Un tipo especial de constructores son las operaciones de COPIA


17

* La copia de objetos no puede ser una operación automática ya que la

estructura de los objetos puede ser tan complicada como muestra la figura.

4) En algunos lenguajes un tipo especial de constructor es la ASIGNACION

* La asignación implica distintas situaciones en: - HEAP: compartición del objeto referenciado - STACK: copia del objeto referenciado * El tratamiento que se da a estos objetos es también distinto en cada lenguaje: - PASCAL: típico - Smalltalk, Eiffel: todos los objetos residen en el HEAP * En C++ la asignación tiene un valor semántico diferente en las siguientes

situaciones: - Puntero o referencia: implica compartición del objeto - Tipos no objetos (salvo array): copia del valor del objeto - Tipos objetos: copia REDEFINIBLE del valor del objeto class TPrueba {public int a; int b;


18

TPrueba (int x, int y) { a = x; b = y } TPrueba& operator= (TPrueba& p) { a = p.a; b = p.b; } } void f() { int i = 1; // initialize i int& r = i // initialize r to i r = 2 // assignment: i and r share the value 2 TPrueba prueba1 (4,5); TPrueba prueba2 (5,6); TPrueba& refPrueba1 = prueba1; TPrueba* ptrPrueba3 = new TPrueba (7,8); TPrueba* ptrPrueba4 prueba1 = prueba2 //Asignment of the value of prueba2 to prueba1 ptrPrueba4 = ptrPrueba3 //Assignment of the value of pointers: sharing delete ptrPrueba3 //ptrPrueba4 points to a deleted object}


19

5) Un tipo especial de observador es la IGUALDAD Esto hace que habitualmente se distingan los siguientes conceptos: 1) IGUALDAD: dos objetos son el mismo objetos. == en Smalltalk == de punteros en C++ = de punteros en Pascal 2) SIMILARIDAD: dos objetos poseen el mismo valor abstracto = en Smalltalk == para objetos en C++ (sobrecargable) igual en Pascal

6) Un tipo especial de modificadores son las operaciones de INICIALIZACION

* Debe garantizar que un objeto es válido como representación de algo a

partir de que comienza a usarse. * La forma típica consiste en aplicar una operación de inicialización

inmediatamente después de la creación de un objeto: new ^super new initialize initialize ..... * Los CONSTRUCTORES en C++ y JAVA son ejemplo típico de

inicializadores tanto para objetos en el HEAP como en el STACK.


20

HEURISTICAS PARA LA ADECUACION DE UN TAD * Un TAD es adecuado si proporciona suficientes operaciones para cubrir

con eficiencia razonable las necesidades que TENDRAN los usuarios de sus objetos.

1) Debe poseer operaciones de todos los tipos considerados más arriba. Los

tipos inmutables carecen de modificadores. 2) El acceso a los elementos de la representación puede reducir

considerablemente el número de operaciones necesarias, pero aumentará el acoplamiento entre clases (LEY DE DEMETER)

3) El exceso de operaciones puede hacer menos comprensible la

abstracción y más difícil la implementación y el mantenimiento 4) Algunas operaciones adicionales podrán implementarse a partir de

operaciones más básicas. El caso de los iteradores es especialmente significativo

5) Si la asignación se puede redefinir se debe ser especialmente cuidadoso

con mantener una semántica parecida para todos las clases 6) La operacion de SIMILARIDAD debe ser redefinida para todos los TAD

(clases).


21

7.4.3 Elección de precondiciones para las operaciones * La precondición indica bajo qué circunstancias se puede realizar la llamada a un

procedimiento. * Se expresan como valores posibles de los parámetros de entrada. * En los lenguajes sin tipos también las clases requeridas a un parámetro se

pueden expresar como precondición. * Precondición RESTRICTIVA: más eficiente y limita su efecto, haciendo la

implementación más sencilla. En general también son menos seguros. * La LAXITUD en las restricciones procedimientos más complejos, con efecto

más amplio, mayor complejidad de implementación y una mayor seguridad. * Métodos de la clase Collection: mezcla: unaCollectionDeInteger Precondición: self y unaCollection deben ser colecciones de

números ordenadas mediante la operación >= Efecto: mezcla ordenadamente self y unaCollectionDeInteger Modifica: Devuelve: la mezcla de ambas colecciones mezcla: unaCollectionDeInteger Precondición: self y unaCollection deben ser colecciones de

números. Efecto: mezcla ordenadamente self y unaCollectionDeInteger Modifica: Devuelve: la mezcla de ambas colecciones


22

8 Propiedades de la representación: FA e IR * FUNCION DE ABSTRACCION: función que determina el objeto abstracto al

que corresponde un objeto rep. * INVARIANTE DE LA REPRESENTACION: predicado que cumplen los

objetos del tipo rep para ser objetos representativos válidos.

9 Consecuencias de diseño de la FA y el IR Desde el punto de vista del diseño ambos conceptos son importantes: 1) El IR determina la FA: en general cuanto más restrictivo sea el IR más

sencilla será la FA. 2) La FA determina la implementación de la operación de SIMILARIDAD: - Si la FA es biyectiva esta implementación puede basarse,

automáticamente, en la SIMILARIDAD de la rep. - Si no lo es debe tener una implementación propia que, a veces,

requiere la implementación de operaciones intermedias de conversión.

3) El IR debe ser garantizado por todas las operaciones que creen o

modifiquen objetos. Esta garantía se suele basar en verificaciones a lo largo de la implementación de las operaciones.

4) Puesto que el IR sólo se puede garantizar para las operaciones del TAD

el lenguaje o el estilo de programación deben garantizar el ocultamiento de información.


23

ELECCION DE LA REPRESENTACION Y LA IMPLEMENTACION Para representar un TAD seleccionaremos la representación de los objetos e implementaremos las operaciones en los términos de esta representación. Esta debe permitir la implementación de las operaciones de forma simple y eficiente. Con frecuencia distintas representaciones son más adecuadas para favorecer operaciones distintas, por lo que debe evaluarse la elección de un representación. Antes de implementar las operaciones debe fijarse el IR y la FA. Aunque el proceso recomendado en la elaboración de un TAD es especificar, representar e implementar surgen interacciones que pueden obligar a modificar la especificación. Ello no invalida el que deba tratar de seguirse el proceso. El lenguaje de programación elegido condiciona incluso la especificación (por ejemplo, la asignación puede aparecer como una operación en C++ y no en Eiffel)


24

10 Interfaces en JAVA

Definición de una interface interface Ejercicio

{ public int distanciaMaximaRecorrida (int tiempo);

public String comer(String comida); } Clases que implementan la interface class Persona implements Ejercicio

{ protected int velocidadMaxima = 40;

public int distanciaMaximaRecorrida (int k) { return ( velocidadMaxima * k) };};

public String comer (String papeo) { return (“Me como: ” + papeo);}; }

class Animal implements Ejercicio {

protected int velocidad = 40;

public int distanciaMaximaRecorrida (int t) { return ( velocidad * t) };};

public String comer (String comida) { return (“Devoro: ” + comida);}; } Uso de la interface Ejercicio: Ejercicio varEjercicio; // La interface se usa como tipo de una variable .... varEjercicio = new Persona(); // Se puede asignar cualquier objeto de una clase varEjercicio.correr(10); //que implemente la interface. varEjercicio = new Animal(); varEjercicio.comer (‘carne”); La interface garantiza un determinado comportamiento por parte de clases diferentes. Es un importante concepto de diseño: permite anticipar el comportamiento de clases aún no definidas.

Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO...

Documents

Transcript of Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO...