Lenguajes de Programación Tema 4. Paradigma Orientado a Objetos Pedro García López pgarcia@etse.urv.es

Lenguajes de ProgramaciónTema 4. Paradigma Orientado a

Objetos

Pedro García Lópezpgarcia@etse.urv.es/

• © University Rovira i Virgili

• Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; A copy of the license is available at:

• http://www.fsf.org/licenses/fdl.html

Copyright

Indice

• Introducción

• Paradigma Orientado a Objetos

• Estudio de caso: Java

• Conclusiones

Paradigma Orientado a Objetos

• Conceptos generales• Clases y Objetos• Herencia • Polimorfismo

Problemas en la creación del software¿Hay crisis del software?

• Gran complejidad– Número de estados posibles es muy elevado– Conexiones entre entidades– Complejidad arbitraria que surge de instituciones

humanas

• Sujeto a continuos cambios• No tiene representación gráfica• Especificación de requisitos• Comunicación del equipo

Calidad del Software

Factores Externos• Corrección• Robustez• Extensibilidad• Reutilización• Compatibilidad

• Modularidad• Legibilidad

Factores Internos

• Eficiencia• Portabilidad• Facilidad de uso• Funcionalidad

Mantenimiento del software

• Parte noble: MODIFICACION

• Parte no noble: DEPURACION

• Se le dedica el 70 % del coste del software

• Distribución coste según [Lientz79]:– Cambios solicitados por los usuarios (41.8%)– Cambios en los formatos de los datos (17.4%)– Cambios de emergencia (12.4%)– Depuración rutinaria (9%)– Costes de documentación (5.5%)

Mantenimiento del software• Conclusiones del estudio:

– Ausencia de extensibilidad– Estructura física de los datos dispersa por

muchas partes del sistema– No se hace documentación a posteriori– Cuando el sistema funciona no se buscan

mejoras en eficiencia.

• Numero de conexiones sea mínimo

• Flujo de información sea mínimo

• Comunicaciones explícitas

Modulo A Modulo B

Modulo C

Modulo A Modulo B

Modulo C

Acoplamiento mínimo:

• Cohesión de datos• Cohesión funcional

Cohesión interna:

En los Sistemas Software interesa ...

Reutilización del software

• ¿Por qué el software no es como el hardware?

• ¿Por qué cada nuevo proyecto software arranca de la nada?

Librerías de softwareSoftware-IC

Repetición en el desarrollo del software

• ¿Cuántas veces en los últimos 6 meses has escrito código para buscar un elemento en una colección?

• Naturaleza repetitiva de la programación (ordenar, buscar, recorrer, ...)

• ¿Por qué no es frecuente?– Dificultades técnicas y no técnicas

Dificultades técnicas

• Diseñar código reutilizable es difícil.

• Hacemos las mismas cosas pero no de la misma forma.

• Difícil captura de las similitudes.

• Permitir adaptación

Ejemplo

Rutina genérica para “búsqueda en una colección”

FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEANVAR

pos : Posicion;BEGIN

pos:= Comenzar (x,c);WHILE not Completa (pos,c) and not Encontrado (pos, x,

c) DO pos:= Siguiente (pos, x, c);buscar:= not Completa (pos,c);

END;

Requisitos de los módulos para facilitar la reutilización

1. Variación en tiposAplicable a diferentes tipos de elementos

x: Elemento

FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEANVAR pos : Posicion;BEGIN

pos:= Comenzar (x,c);WHILE not Completa (pos,c) and not Encontrado (pos, x,

c) DO pos:= Siguiente (pos, x, c);buscar:= not Completa (pos,c);

END;

Requerimientos de los módulos para facilitar la reutilización

2. Variación en estructuras de datos y algoritmosEl tipo Coleccion puede estar implementado de diferentes formas y Siguiente(pos,x,c) puede estar ligado a diferentes rutinas:

FAMILIAS DE MODULOS relacionados

FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEANVAR pos : Posicion;BEGIN

pos:= Comenzar (x,c);WHILE not Completa (pos,c) and not Encontrado (pos, x,

c) DO pos:= Siguiente (pos, x, c);buscar:= not Completa (pos,c);

END;

Requerimientos de los módulos para facilitar la reutilización

3. Independencia de la representaciónSe puede usar una operación sin conocer su implementación

siguiente(pos,x,c), comenzar(x,c),

encontrado(pos,c), completa(pos,c)

FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEANVAR pos : Posicion;BEGIN

pos:= Comenzar (x,c);WHILE not Completa (pos,c) and not Encontrado (pos, x,

c) DO pos:= Siguiente (pos, x, c);buscar:= not Completa (pos,c);

END;

Independencia de la representación

Alternativa:

if “c es de tipo A” then “aplicar algoritmo de búsqueda A”

elseif “c es de tipo B” then “aplicar algoritmo de búsqueda B”

elseif …

• Este código sería incluido en:– Un único módulo: Grande y sujeto a constantes

cambios– Código cliente: Dificulta la extensibilidad

Requerimientos de los módulos para facilitar la reutilización.

4. Factorizar comportamientos comunes dentro de una familia de implementaciones

5. Rutinas relacionadas

FUNCTION buscar (x: Elemento; c: Coleccion): BOOLEANVAR pos : Posicion;BEGIN

pos:= Comenzar (x,c);WHILE not Completa (pos,c) and not Encontrado (pos, x,

c) DO pos:= Siguiente (pos, x, c);buscar:= not Completa (pos,c);

END;

Tabla

Secuencial Conjunto

Lista Array

• La operación “búsqueda” se escribe una sola vez.

Ejemplo: Factorizar comportamientos comunes

FicheroSecuencial

FUNCTION busqueda (x: elemento; t:Secuencia): BOOLEANBEGIN

Comenzar;WHILE not Completa and not Encontrado(x) DO

Avanzar;busqueda:=not Completa;

END;

ARRAY LISTAENLAZADA

FICHEROSECUENCIAL

Comenzar i:=1 l:=cabeza resetAvanzar i:=i+1 l:=l^.next readCompleta i>tamaño l=nil eofEncontrado t[i] = x l^.item = x f^= x

Una nueva variante sólo tiene que especificar cómo implementar estas cuatro rutinas

Estructuras modulares tradicionales

• Rutinas• Paquetes o Módulos

¿Por qué no son suficientes?

Posibles soluciones para darles flexibilidad:• Sobrecarga • Genericidad

¿cubre los requisitos de módulos reutilizables?

Rutinas• Unidad de software que puede llamar a otras unidades para

ejecutar un cierto algoritmo.

• Enfoque de reutilización: librerías de rutinas

• Adecuadas en áreas donde pueden ser identificado un conjunto de problemas individuales con las siguientes limitaciones:

1. Admiten especificación simple: pequeño conjunto de parámetros.2. No estén implicadas estructuras de datos complejas.3. Problemas claramente diferenciados.

Limitaciones de las rutinas• Soluciones para: "Búsqueda en una colección secuencial”:

1) Una rutina:• "CASE" enorme.• Muchos argumentos.

2) Conjunto de rutinas:• Rutinas muy similares ( factorizar comportamiento)

• Cliente debe buscar en un laberinto de rutinas.

Conclusión: Un módulo reutilizable debe estar abierto a la adaptación y, la única forma de adaptación de una rutina es pasarle diferentes argumentos.

Las rutinas no son suficientemente flexibles

Paquetes/Módulos• Son unidades de descomposición de software que:

– Cumplen el principio de Unidad Lingüística Modular

– Contienen variables y rutinas relacionadas = características del

`paquete

– Admiten la Ocultación de la Información (módulos abstractos)

– Permite la implementación de tipos definidos por el programador

• Los módulos sólo resuelven ”rutinas relacionadas”

– facilita depuración y cambio al proveedor

– es más fácil para los clientes encontrar y usar los servicios de los

módulos

Ejemplo: Paquetes/Módulos

Package TablaEnteros;type ArbolBinEnteros

recordinfo: Integerizq, der: ArbolBinEnteros

end;

new: ArbolBinEnteros begin … end; añadir(t:ArbolBinEnteros; x: Integer) begin … end; existe(t:ArbolBinEnteros; x: Integer): Boolean begin ..

end

….end

DECLARACIÓN DE TIPO

OPERACIONES SOBRE EL

TIPO

PAQUETE

Sobrecarga

• Identificador con más de un significado.

• Ejemplo: Sobrecarga de rutinas

FUNCTION Búsqueda (x:Cuenta; t: ListaCuentas): Boolean;

FUNCTION Búsqueda (x:CHAR; t: ARRAY [CHAR]): Boolean;

FUNCTION Búsqueda (x:REAL; t: ARRAY[REAL]): Boolean;

• Facilidad sintáctica orientada a los clientes.

• Permite escribir el mismo código cliente usando diferentes implementaciones de cierto concepto.

¿Qué nos proporciona la sobrecarga?

• ¿ Resuelve “Variación en estructuras de datos y algoritmos”?

• ¿Resuelve “Independencia de la representación”?

• En cada invocación “Busqueda(x,t)” cliente y compilador saben de que versión se trata.

• “Independencia en la representación” exige poder escribir “Busqueda(x,t)” significando:

“Busca x en t usando el algoritmo adecuado, cualesquiera que sea la clase de colección ligada a t en tiempo de ejecución”

Genericidad• Posibilidad de definir módulos parametrizados, cuyos

parámetros representan tipos.

• Facilidad orientada a los creadores de módulos permite

escribir el mismo código cuando se usa la misma

implementación de cierto concepto, aplicado a

diferentes tipos de objetos” Ej: Array [T],

Lista[T]

• Los módulos cliente deben instanciar el módulo

genérico Ej: Array [Real],

Lista[Figura],

• Resuelve “variación en tipos”

Ejemplo de Genericidad

Package Tabla[T];type ArbolBinario

recordinfo: Tizq, der: ArbolBinEnteros

end;

new: ArbolBinario begin … end; añadir(t:ArbolBinario; x: T) begin … end; existe(t:ArbolBinario; x: T): Boolean begin .. end

….end

• La genericidad resuelve:

Variación en tipos.

• Los paquetes/modulos resuelve:

Rutinas relacionadas.

• No se resuelve:Variación en estructuras de datos y algoritmos.

Independencia de la representación.

Capturar similitudes entre un subgrupo de un conjunto de posibles implementaciones.

Conclusión

Descomposición Funcional

A

B C D

E HGF

Secuencia

Bucle

Condicional

Inconvenientes de la Descomposición Funcional

• Función principal: “Cima del sistema”– El “programa principal” es una propiedad

volátil– Sistemas reales no tienen “cima”– Mejor la visión de un “conjunto de servicios”

• Centrado en la interfaz– Primera pregunta: ¿Que hará el sistema?– La arquitectura del software debe basarse en

propiedades más profundas.

• Ordenación temporal prematura

Inconvenientes de la Descomposición Funcional

• No favorece la reutilización– Se desarrollan elementos software para satisfacer

necesidades específicas de otro elemento del nivel superior.

– “Cultura del proyecto actual”

• Las estructuras de datos son descuidadas– Funciones y datos deben jugar un papel

complementario

• Cuando un sistema evoluciona los datos son más estables que los procesos.

Ventajas de la Descomposición Funcional

• Técnica simple, fácil de aplicar

• Util para pequeños programas y describir algoritmos.

• Buena para documentar diseños.

• Facilita desarrollo sistemático de sistemas

• Adecuada para dominar la complejidad

Descomposición basada en objetos

• Los objetos son más estables que las funciones cuando el sistema evoluciona (Extensibilidad).

• Tipos de objetos equipados con las operaciones asociadas (Reutilización).

• El diseñador lista las operaciones aplicables a cierto tipo de objetos, especificando su efecto.

• Se retrasa todo lo posible el orden en que se ejecutan las operaciones.

Desarrollo software OO

1. Encontrar tipos de objetos relevantes

2. Encontrar operaciones para tipos de objetos

3. Describir tipos de objetos

4. Encontrar relaciones entre objetos

5. Usar tipos de objetos para estructurar software

Conceptos Clave POO• Clase y Objeto• Clase: Atributos y métodos• Creación de clases: constructores e instanciación• Invocación de métodos• Atributos y métodos de clase• Ocultación de información• Tipos referencia, asignación, aliasing y copia de objetos• Concepto de Metaclase• Relaciones entre clases: clientela y herencia• Tipos de herencia• Polimorfismo y ligadura dinámica

Clases y Objetos

Una clase es un módulo y un tipo de dato:

• Módulo (concepto sintáctico)

– Mecanismo para organizar el software (sintáctico)

– Encapsula componentes software

• Tipo (concepto semántico)

– Mecanismo de definición de nuevos tipos de datos:

describe una estructura de datos (objetos) para representar

valores de un dominio y las operaciones aplicables.

Combinación módulo-tipo

“Los servicios proporcionados por una clase, vista como un módulo, son precisamente las operaciones disponibles sobre las instancias de la clase, vista como un tipo”.

• Como cada módulo es un tipo, cada operación del módulo es relativa a cierta instancia del tipo

TAD y Clase

Teoría

TAD

{Operaciones: Sintaxis

y Semántica}

Software

Clase

{Elegir representación e

implementar operaciones}

Clases: Ejemplo• Al modelar un banco, encontramos objetos

“cuenta”.

• Todos los objetos “cuenta” tienen unas propiedades comunes:– saldo, titular, código, reintegro, ingreso, …

• Definimos una clase Cuenta.

• Clases del dominio y clases de diseño/implementación

Componentes de un clase• Atributos

– Determinan una estructura de almacenamiento para cada objeto de la clase

• Rutinas (Métodos)– Operaciones aplicables a los objetos– Único modo de acceder a los atributos

Ejemplo: Al modelar un banco, encontramos objetos “cuenta”.

Todos los objetos “cuenta” tienen propiedades comunes:

• atributos: saldo, titular, ...• operaciones: reintegro, ingreso, …

Definimos una clase CUENTA.

Cada objeto es instancia de una clase

Clase Cuenta

Objeto Cuenta

Objeto Cuenta

Objeto Cuenta

Objeto CuentaInstanciación

Cada objeto es instancia directa de una clase.

Una clase es una factoría de objetos

Estructura de datos

Cuenta ococ = new Cuenta()

Código

Constructores (C++ y Java)

• Realizan la inicialización de un objeto tras la creación.

• Un constructor – procedimiento especial con el mismo nombre que

la clase.– Se debe invocar cuando se crea un objeto de la

clase con el operador new– En C++ también cuando se declara una variable.– Pueden tener modificadores de acceso

Mensajes

• Mecanismo básico de la computación OO.

• Invocación de la aplicación de un método sobre un objeto.

• La modificación o consulta del estado de un objeto se realiza mediante mensajes.

• Formado por tres partes

– Objeto receptor– Selector o identificador del método a aplicar– Argumentos

Semántica mensajes

• Sea el mensaje x.f, su significado es:

“Aplicar el método f sobre el receptor x, efectuando el paso de parámetros”

¡NO CONFUNDIR CON LA INVOCACIÓN DE UN PROCEDIMIENTO!

Variables y métodos de Clase• Compartida por todas las instancias de una

clase.

• Registrar valor común a todas las instancias

• Ejemplos para una clase Cuenta:– Interés, Coste tarjeta, Último código asignado

• ¿Cuándo se inicializa?

• Puede ser accedida por métodos de instancia y de clase

• Los métodos de clase no deberían acceder a variables de instancia

Clases y Ocultación de Información

• Ocultamiento información importante para conseguir arquitecturas flexibles y coherentes.

• Interface vs. Implementación:– Un cliente sólo conoce la interface.

– Sólo los métodos de la clase deberían poder acceder a sus atributos.

• Cada lenguaje OO (Eiffel, C++, Java, Smalltalk) presenta diferencias en cuanto al ocultamiento de información.

Tipos referencia• Los posibles valores de una entidad (atributo,

parámetro, …) son referencias a objetos potenciales que pueden ser creados en tiempo de ejecución a través, siempre, de instrucciones de creación explícitas.

• Una referencia puede encontrarse en uno de dos estados posibles– No ligada: Void (Eiffel) o null (Java)– Ligada a un objeto

• Las referencias son “punteros domesticados”.• Void es un estado (null es un literal) mientras que “nil”

(en Pascal) o “null” (en C) son valores de tipo puntero.

Ventajas de los tipos referencia

• Más eficiente para manejar objetos complejos.

• Soporte para definir estructuras de datos recursivas.

• Soporte del polimorfismo.

• Los objetos son creados cuando son necesarios.

• Permite la compartición de un objeto (integridad

semántica).

• DESVENTAJA: “Aliasing”

¡Cuidado con el Aliasing!

oa ob

oa:= ob

oboa

La asignación no implica copia de valores sino dereferencias

Asignación

Solución: Copia de objetos

• Copia superficial– Se copian los valores de cada campo del objeto

origen oy en el objeto destino ox; ox y oy comparten referencias.

– Soportada por defecto y puede redefinirse para una clase concreta.

• Copia profunda– Se crea un objeto con una estructura idéntica al

objeto origen.– No hay compartición de referencias– No suele ser soportada por defecto

Metaclases

• Una clase puede ser considerada un objeto:– ¿Cuál es su clase?

• Metaclase– Clase que describe clases, sus instancias son

clases.– Propiedades: lista de atributos, lista de variables

de clase, lista de métodos, lista de métodos de clase.

• Java y Smalltalk tienen metaclases• Útil en programación avanzada, cuando se manejan

entidades software, p.e. depuradores, inspectores, browsers,..

Relaciones entre clases• Clientela

Una clase A es cliente de una clase B, si A contiene una declaración en la que se establezca que cierta entidad (atributo, parámetro, variable local) e es de tipo B (e:B)

Ejemplo: titular: Persona

CUENTA PERSONA

“Cuenta es cliente de Persona”• Herencia Una clase es una versión especializada de otra existente

Ejemplo:

Cuenta

CuentaAhorro CuentaCorriente

Herencia

PUBLICACION

LIBRO REVISTA

LIBRO_TEXTO INVESTIGACIONMAGAZINE

FIGURA

POLIGONO CIRCULO

RECTANGULO

La herencia organiza las clases en una estructura jerárquica:

Jerarquías de clases

Ejemplos:

• No es tan solo un mecanismo para compartir código.

• Consistente con el sistema de tipos del lenguaje

Herencia• Puede existir una clase “raíz” en la jerarquía de la

cual heredan las demás directa o indirectamente.

• Incluye todas las características comunes a todas las clases

Eiffel: clase ANYSmalltalk: clase ObjectJava: clase ObjectC++: no existe

HerenciaSi B hereda de A entonces B incorpora la estructura (atributos) y comportamiento (métodos) de la clase A, pero puede incluir adaptaciones:

-B puede añadir nuevos atributos-B puede añadir nuevos métodos

-B puede REDEFINIR métodos

-B puede renombrar atributos o métodos- B puede implementar un método diferido en A

…

Adaptaciones dependientes del lenguaje(Redefinición disponible en cualquier LOO)

•Refinamiento: Extender el uso original

•Reemplazo: Mejorar la implementación

Polimorfismo• Es restringido por la herencia

• Importante para escribir código genérico

• Sea las declaraciones:ox: X; rutina1 (oy:Y)

– En un lenguaje con monomorfismo (Pascal, Ada, ..) en t.e. ox y oy denotarán valores de los tipos X e Y, respectivamente.

– En un lenguaje con polimorfismo (Eiffel, C++, ..) en t.e. ox y oy podrán estar asociados a objetos de varios tipos diferentes:

tipo estático vs. tipo dinámico

Tipo estático y tipo dinámico

• Tipo estático: – Tipo asociado en la declaración

• Tipo dinámico: – Tipo correspondiente a la clase del objeto conectado a

la entidad en tiempo de ejecución

• Conjunto de tipos dinámicos:– Conjunto de posibles tipos dinámicos de una entidad

oa: A; ob: B; oc; C;

te(oa) = A ctd(oa) = {A,B,C,D,E,F}

te(ob) = B ctd(ob) = {B, D, E}

te(oc) = C ctd(oc) = {C,F}

A

ED

CB

F

Ejemplo:

Conexión polimorfa

• Cuando el origen y el destino tiene tipos diferentes:a) asignación:

p := r; -- p es una entidad polimorfa

b) paso de parámetros: f (p:POLIGONO) is do ... end -- f es una rutina

polimorfa

• Sólo se permite para entidades destino de tipo referencia

(POLIGONO)p

(antes)

(después)

(RECTANGULO)

r

p:POLIGONO; r:RECTANGULO

Tipos de polimorfismo• Real

– Paramétrico (“lista de T”)– Inclusión:

• Basado en la herencia• una función y varias interpretaciones diferentes

• Aparente– Sobrecarga

• varias funciones todas con el mismo nombre

Ejemplo polimorfismo paramétrico:long (l:lista): integer

if l=nil then long:=1else long:= 1 + long(cola(l))

Sobrecarga

• Es el nombre de la función lo que es polimórfico

• Se resuelve en tiempo de compilación, según la signatura de la rutina.

• No es necesario que exista similitud semántica.

• En los lenguajes OO puede existir sobrecarga– dentro de una clase

– entre clases no relacionadas (es fundamental)

Polimorfismo y código genérico• Estructuras de datos polimórficas:

Pueden contener instancias de una jerarquía de clases

• Ejemplo: fig: ARRAY [FIGURA]

p: POLIGONO; r: RECTANGULO; c: CIRCULO;t:TRIANGULO;

!!p; !!r; !!c; !!t;

fig.put (p,1); fig.put (r,2); fig.put (c,3); fig.put (t,4); ...

1

2

3

4

fig

Genericidad

• ¿Cómo escribir una clase que represente una estructura de datos y que sea posible almacenar objetos de cualquier tipo?

Pila-Enteros

Pila_Libros Pila de ?Pila_Figuras

….

• Necesidad de reconciliar reutilización con el uso de un lenguaje tipado.

Herencia

ColeccionEntero

ListaEntero

ListaCircularEntero

ColeccionTarea

GrafoTarea

RedTarea

class ListaEntero inherit ColeccionEntero feature

numElements: Integer is do ..

añadir (i: Integer, v:Integer) is do ..

iesimo (i:Integer): Integer is do ..

buscar (v:Integer): Boolean is do ..

...

end ¿Cómo asociar a v un tipo pero sin hacer que la clase sea dependiente del tipo de objeto almacenado?

Genericidad

Coleccion [G]

Lista [G]

ListaCircular [G]

class Lista [G] feature

numElements. Integer is do ..

añadir (i: Integer, v:G) is do ..

iesimo (i:Integer): G is do ..

buscar (v:G): Boolean is do ..

...

end

miLista1: Lista [Integer] miLista2: Lista [Punto]

Genericidad

• Posibilidad de parametrizar las clases; los parámetros son tipos de datos.

• Facilidad útil para las clases que representan estructuras de datos generales: TIPO BASE ES UN PARAMETRO

class ARRAY [G], class PILA [G], class LISTA [G], ...

• Orientada a los creadores de clases