Download Tema 4.- TDA, polimorfismo y clases

Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
Tema 4.- TDA, polimorfismo y clases
1
2
3
4
La clasificación en OO.......................................................................................................2
Concepto de polimorfismo.................................................................................................3
Polimorfismo en los LOO..................................................................................................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
1
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
2
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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).
3
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
4
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
5
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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);
6
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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
7
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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
8
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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
9
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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
10
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
* 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
11
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
12
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
- 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.
13
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
14
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
15
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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
16
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
* 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;
17
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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}
18
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
19
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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).
20
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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
21
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
22
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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)
23
Programación Dirigida a Objetos . MATERIAL COMPLEMENTARIO
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.
24