PDF de programación - Lenguajes de programación orientados a objetos y basados en prototipos

Lenguajes de programación
orientados a objetos y basados

en prototipos

Grupo IMO

Área de Lenguajes y Sistemas Informáticos

Departamento de Informática

Conferencia en la Escuela Superior de Informática,

Universidad de Valladolid

J. Baltasar García Perez-Schofield

http://webs.uvigo.es/jbgarcia/

El modelo de orientación a objetos

basado en prototipos

Características básicas

Orientación a objetos basada en

prototipos

➲ Existen dos corrientes principales:

● Lenguajes orientados a objetos basados en

clases: C++, Object Pascal, Java, Eiffel ... son
los más utilizados por la industria.

● Lenguajes orientados a objetos basados en pro-
totipos: Self, Kevo, Poet/Mica, Cecil ... son todos
ellos experimentales, es decir, no se utilizan en
la industria.

Terminología

➲ Estado: los atributos (terminología SmallTalk) o
datos miembro (terminología C++) de un objeto.
En el caso de un coche, su color, su longitud,
cilindrada, ...

➲ Comportamiento: los métodos (SmallTalk) o
funciones miembro (C++) de un objeto. En el
caso de un coche, arrancar, acelerar, frenar,
apagar.

➲ Mensaje: ejecución de un método de un objeto.
Si un objeto tiene un método f(), mandarle a O
el mensaje f es lo mismo que ejecutar O.f()

Orientación a objetos basada en

clases

➲ Una clase es un

“tipo” de objetos, es
decir, un molde del
que se obtienen
nuevos objetos, que
comparten similar
comportamiento,
cambiando el esta-
do de los mismos.

Orientación a objetos basada en

prototipos

➲ No existen las

clases. De hecho,
todos los objetos
son iguales en
cuanto a categoría.
➲ Los nuevos objetos
se copian de otros
ya existetntes. Al-
gunos de ellos son
prototipos.

Orientación a objetos basada en

prototipos

➲ Normalmente, en este

tipo de lenguajes los
objetos pueden modi-
ficarse, añadiendo o
borrando métodos y
atributos.

➲ Cada objeto es inde-
pendiente, no necesi-
tando información ex-
tra de ningún tipo.

Herencia

➲ La herencia en lenguajes basados en pro-

totipos suele ser por delegación.
● El objeto tiene uno o más aributos parent, de
forma que cuando no puede responder a un
mensaje, le reenvía éste a su padre.

➲ En el caso de los lenguajes basados en
clases, ésta suele presentarse como con-
catenación
● El objeto está compuesto por las partes que de-
fine cada una de las clases de las que hereda.

Herencia mediante delegación

➲ Existe una cadena
de objetos apuntan-
do a sus padres,
hasta llegar a un ob-
jeto padre de todos.

Comparativa:
Comparativa:

el modelo basado en clases re--
el modelo basado en clases re
specto al modelo basado en pro--
specto al modelo basado en pro

totipos
totipos

Creación de objetos
Creación de objetos

Creación de Objetos

➲ Al crearse los nuevos objetos mediante

copia, no es necesario que existan los con-
structores de los lenguajes orientados a ob-
jetos basados en clases.

➲ Los objetos no sólo definen los tipos de

datos de los atributos, como en las clases,
sino que además ya tienen un valor asocia-
do.

Creación de Objetos

➲ Por ejemplo:
object Persona
attribute + nombre = “Juan”;
attribute + apellidos = “Nadie”;
attribute + telefono = “906414141”;
attribute + edad = 18;
attribute + direccion;
method + toString()
{
return nombre.concat( apellidos );
}
endObject

Creación de objetos

➲ El objeto Persona es un prototipo que

servirá para crear nuevos objetos, aunque
no existe ninguna diferencia entre un pro-
totipo y cualquier otro objeto.

➲ Por ejemplo:

Persona.copy( “paulaMarquez” );

➲ Si se le envía el mensaje copy al objeto Per-

sona, entonces se creará un nuevo objeto
copia exacta de Persona, con el nombre
“PaulaMarquez”, cuyos atributos deberán
ser modificados convenientemente.

Creación de objetos

➲ Crear un objeto de Persona:

reference paula;
paula = Persona.copy( “paulaMarquez” );
paula.ponNombre( “Paula” );
paula.ponApellidos( “Márquez Márquez” );
paula.ponTelefono( “988353535” );
...

La copia puede ser costosa

➲ El prototipo (separado en rasgos y estado) es el

padre de los objetos que son instancias de él.
➲ Se emplea la herencia de manera conveniente.

Ejemplo de traducción en C++

➲ El siguiente programa:
class Coche {
public:

int numRuedas;
int color;
int combustible;
static void encontrarGasolinera();
void arranca();

Coche micoche;

};
//...
int main(void) {

miCoche.color = 1; /* BLANCO */

}

micoche.arranca();

Ejemplo de traducción en C++

➲ Sería traducido como:
struct Coche {
int numRuedas;
int color;

// ...

}
void Coche_encontrarGasolinera() {
}
void Coche_arranca(struct Coche &this) {
// ...
}
int main(void)
{

struct Coche miCoche;
miCoche.color = 1; /* BLANCO */
Coche_arranca(&miCoche);

}

Comparativa: Herencia.
Comparativa: Herencia.

Herencia por concatenación

➲ Todos los atributos y métodos heredados están
disponibles en el mismo objeto (si bien se nece-
sita la clase para poder interpretarlos).

Herencia mediante delegación

➲ Existe una cadena
de objetos apuntan-
do a sus padres,
hasta llegar a un ob-
jeto padre de todos.

Respuesta a mensajes

➲ Cuando un objeto no puede responder un
mensaje, porque no posee el miembro (a-
tributo o método), que se le pide, reenvía el
mensaje al objeto que marca su atributo
parent.

➲ Las relaciones de herencia, en lugar de ser
un caso aparte, pasan a ser un caso particu-
lar de las relaciones de composición.

Respuesta a mensajes

➲ Ejemplo. Dados los objetos:

object A
method + foo()
{
System.console.write( “foo” );
return;
}
endObject
object B: A
endObject

Respuesta a mensajes

➲ El mensaje:

B.foo(); // MSG B foo

➲ No encuentra el método foo() en el objeto B,

así que se sigue el atributo parent, que
apunta a A, que sí tiene ese método, y es
ejecutado.

➲ Si no se encontrara, entonces se produciría

un error, que normalmente se traduce en
una excepción. En este caso, la excepción
producida sería “Método no encontrado”.

Herencia dinámica

➲ En el caso de estar implementada por dele-

gación, se abre una nueva posibilidad: el
hecho de poder cambiar el atributo (ya que,
normalmente, es un atributo más) que
señala al padre del objeto, hace que un obje-
to pueda ser “hijo” de varios objetos, depen-
diendo del momento de la ejecución.

➲ El aprovechamiento de esta característica
requiere cambiar ligeramente el tipo de pro-
gramación.

Herencia dinámica

➲ Es posible cambiar,
en tiempo de ejecu-
ción, al “padre” de
un objeto.

➲ Es totalmente con-
trario a la corriente
actual, que trata de
detectar todos los
errores posibles en
tiempo de compi-
lación.

Herencia dinámica

➲ En el método insertar de ListaUnElemento:

object ListaUnElemento: Lista
method + insertar(n, obj)
{
super( 1, obj );
parent = ListaNoVacia;
return;
}
method + getElementoNumero(n)
{
return parent.getPrimerElemento();
}
endObject

Herencia dinámica
➲ En el método borrar de ListaNoVacia:

object ListaNoVacia: Lista
method + borrar(n)
{
super( n );
if ( this.getNumeroElementos()
== 1 ){
parent = ListaUnElemento;
}
return;
}
endObject

Herencia dinámica

➲ En el lenguaje Prowl:

object ListaPersonas:

ListaVacia( this.size() == 0 ),
ListaUnElemento( this.size() == 1 ),
ListaNoVacia( this.size() > 1 )

endObject

Herencia dinámica

➲ Su principal ventaja reside en que los métodos

pueden escribirse según el tipo del objeto. En Lis-
taVacia, no es necesario que getNumeroElemen-
tos() consulte el tamaño de la lista, sólo debe de-
volver cero. Puede ayudar a solucionar errores y
hacer el código más simple.

➲ Su principal desventaja es que precise coordinar

varios tipos para realizar una serie de tareas. Ésto
puede conllevar errores y puede hacer las modifi-
caciones de código más simples o más compli-
cadas..

Conclusiones de la comparativa:
El modelo de prototipos incluye

al de clases

➲ Los objetos que sirven de prototipos son equiva-
lentes a las clases de aquellos lenguajes orienta-
dos a objetos basados en clases.

➲ La diferencia es que este modelo es mucho más

flexible que el de clases.

➲ Incluso una “clase” en este modelo puede modifi-

carse, al no ser más que un objeto.

➲ La delegación es un mecanismo altamente flexi-
ble, separando a los objetos de sus prototipos,
como en los lenguajes basados en clases, pero
no al comportamiento del estado.

Conclusiones de la comparativa:
¿Cuál es el papel de la clase?

➲ La clase no desaparece, sino que se transforma:

● Sigue siendo necesaria.
● ... pero es un objeto más en el sistema.
● ... manipulable y flexible, en lugar de rígida e inmodifi-

cable.

Patrones de diseño y prototipos
Patrones de diseño y prototipos

Prototype

➲ Copiar una instancia prototípica.

● Un ejemplo podría ser el de las fichas del juego

de las Damas.

➲ Es una característica inherente a los lengua-

jes basados en prototipos.
● No se pueden crear objetos de ninguna otra for-

ma.

➲ A veces, la copia no es suficiente.

● Copiar todo un objeto (comportamiento incluído),

puede ser demasiado costoso. Ésto se puede
paliar.

Bridge

➲ Una jerarquía de clases presenta abstrac-
ciones, mientras otra presenta implementa-
ciones.
● El objetivo es permitir varias implementaciones o

distinguir entre funcionalidades.

➲ En un lenguaje basado en prototipos, es

posible emplear la herencia dinámica.
● La abstracción cambia de implementación cuan-

do sea necesario.

➲ Se puede, sin embargo, emplear el mismo
diseño que en el modelo basado en clases.

Decorator

➲ Añadir más funcionalidades.

● El objetivo es complementar (“decorar”) objetos

con nueva funcionalidad.

➲ En un lenguaje basado en prototipos, se
emplea la misma técnica que en clases.
● Aunque sólo se aporta la decoración en sí.

➲ Se puede emplear herencia.

Proxy

necesario hacerlo.
● Algunas clases puede ser necesario traerlas

desde el disco o por una conexión de red.

➲ “Traer” el objeto/clase real sólo cuando es

➲ En un lenguaje basado en prototipos, se
emplea la misma técnica que en el patrón
decorator.
● Se