Introducción a la Orientación a Objetos

© David Cabrero Grupo MADS - UDC 2

Breve historia de la OO

● 1960s. Simula incorpora características propias de la OO.

● 1970s. Smalltalk. Lenguaje totalmente OO.

● 1990s. “Boom” de la OO.

● 2000-Hoy. Época dorada de la OO.

“Si yo tuviera que vender mi gato (al menos a un informático), no diría que es amable y autosuficiente y que se alimenta de ratones: más bien diría que está orientado a objetos”

Roger King


Metodologías y OO

● Presente en todas las fases de la metodología de desarrollo:

Diseño

Implementación

Validación

Mantenimiento

Análisis


Breve historia de UML

● Representar artefactos en metodologías OO

● 1990s:

- James Rumbaugh: OMT, Grady Booch: Booch's method, Ivar Jacobson: OOSE

- Unified Modelling Language (UML)

ISO/IEC 19501:2005 Information technology — Open Distributed Processing — Unified Modeling Language (UML) Version 1.4.2.

● UML es el estándar adoptado por la industria

● Última versión: UML 2.0 (2.1.x)


OO desde la Programación Estructurada

● OO como evolución del concepto de TAD

- Un objeto es una entidad simple

- Los sistemas complejos se forma estableciendo relaciones entre objetos

- Una aplicación es un conjunto de objetos que interactúan entre sí mediante paso de mensajes

- El control de la aplicación viene dado por el orden en que se envían los mensajes


OO y Paso de Mensajes (i)

● Paso de mensajes

- Un objeto envía un mensaje a otro, invocando una operación

- El receptor ejecuta el método correspondiente y devuelve el resultado

controladorPedidos

pasarelaDePago almacen

1: validarPago()2: enviarPedido()


OO y Paso de Mensajes (ii)


- Visión ortodoxa● Cada objeto es un thread de ejecución independiente● Paso de mensajes = mensajes entre threads

- Implementaciones actuales● Inicialmente un único thread● Paso de mensajes = llamada a función● Manejo explícito de threads y RPCs


Visión General de la OO

- Problemas que pretende resolver la OO:

Mantenimiento | Extensibilidad | Reutilización

- ¿ Cómo ? Idea inicial: las entidades (objetos) del dominio son la parte más estable del sistema

- Características básicas de la OO:● Abstracción. El objeto representa entidades cercanas al

dominio del problema, no a la máquina● Encapsulación. El objeto oculta su información, los demás

objetos acceden a su información a través de una interface definida por él (concepto de caja negra)


Ejercicio

● Identificar posibles objetos en una aplicación de mensajería instantánea

● ¿ Qué problemas propios de la OO nos hemos encontrado ?

- Identificar objetos

- Establecer atributos y métodos


Introducción a UML (i)

- Es en su mayoría un lenguaje gráfico

- Cubre análisis, diseño, despliegue

- Extensible, sus componentes son opcionales

- Abierto a interpretación (p.e. implementar un diseño)


Introducción a UML (ii)

● Distintos tipos de diagramas para expresar distintos aspectos del desarrollo:

- Diagrama de casos de uso

- Diagrama de clases, de paquetes, de componentes

- Diagrama de secuencia, de colaboración, de actividad, de estados

- Diagrama de despliegue

- ...

● Especificación: ~ 1.000 páginas


Introducción a UML (iii)

● Herramientas de UML

- Papel y lápiz

- Software de dibujo especializado

- Herramienta integrada en un entorno de desarrollo


Propiedades de los objetos (i)

● Objeto: "encapsulamiento de un conjunto de operaciones (métodos) que pueden ser invocados externamente, y de un estado que recuerda el efecto de los servicios"

"Análisis y diseño detallado de Aplicaciones informáticas de gestión" [Piattini et al., 1996]


Propiedades de los objetos (i)

● Estado

- Viene dado por el valor de sus atributos

- Cambia a medida que se ejecuta el programa

unaLista

- items = [“abc”,”foo”,”bar”]- last = 3- it =2

+ añadir(item:string)+ borrar(item:string)+ elemento_en(i:int):string+ siguiente():string


Propiedades de los objetos (ii)

● Identidad

- Cada objeto tiene identidad propia, independientemente de su estado.

otraLista

- items = [“abc”,”foo”,”bar”]- last = 3- it = 2

unaLista



Propiedades de los objetos (iii)

● Comportamiento

- Todo objeto posee un conjunto de métodos que determinan su comportamiento

unaListaOrdenada

- items = [“abc”,”bar”,”foo”]- last = 3- it = 2


unaLista




Propiedades de los objetos (iv)

● Tiempo de vida

- El objeto existe durante un período finito de tiempo.

- La mayoría una parte de la ejecución del programa


Resumen

● OO cubre el ciclo de desarrollo completo

● Características:

- Abstracción

- Encapsulación


● UML

● Objeto

- Encapsula:● Atributos● Métodos

- Propiedades:● Estado● Identidad● Comportamiento● Tiempo de vida


LOO basado en prototipos o clases

● Basado en prototipos

- Javascript, self, ...

- Menos populares (salvo javascript)

- Un objeto se crea duplicando otro objeto existente

● Basado en clases

- Java, C#, C++, Ruby, Smalltalk, Eiffel, ...

- Más extendidos

- Los objetos se crean a partir de clases


Clases

● Clase: definición abstracta de un objeto.

conjunto de, plantilla, definición de, ...

“Una clase es una descripción de un conjunto de objetos que manifiestan los mismos atributos, operaciones, relaciones y la misma semántica”

(Object Modelling and Design [Rumbaught et al., 1991])

“Una clase es un conjunto de objetos que comparten una estructura y un comportamiento comunes”

[Booch G., 1994]


Especificación de una clase

● Definición de una clase:

- Nombre de la clase

- Lista de atributos

- Lista de métodos


Clases. Problemas de diseño

● No Bajo acoplamiento

● Clases sin métodos


Visibilidad (i)

● Visibilidad de atributos y métodos

- Público

- Privado

● Los atributos públicos rompen la encapsulación

selectores / modificadores (getters / setters)

métodos públicos: interface (contrato)


Visibilidad (ii)

● Ámbitos especiales:

- Protegido (#)

- Paquete (~)

● Solucionan problemas de implementación, no de diseño


Instanciación

● Crear un objeto (instancia) a partir de la definición de una clase


Clases. Convenciones

● Nombres de las clases

- Guía de estilo. P.e. CamelCase

- Singular

- Sustantivos

● Nombres de los atributos

- Privados comenzando por subrayado “_”


Paquetes (i)

● Un paquete (package) es una agrupación de clases relacionadas.

● Favorece el reuso y la creación de librerías.

● Los LOO suelen tener soporte de paquetes.


Paquetes (ii)

● Estereotipos y relaciones entre paquetes


Relaciones (i)

● Permiten

- Intercambio de mensajes

- Composiciones complejas de objetos

● Tipos de relaciones

- Dependencia

- Generalización

- Asociación

- Agregación / composición


Relaciones (ii)

● Datos de una relación

- Cardinalidad

- Navegabilidad

- Restricciones


Asociación

● Relación de tipo general


Implementación de asociaciones

● Las relaciones se implementan como atributos según su cardinalidad

- 0..1 => referencia

- 0..n => colección (lista, array, ...)

● Los atributos no se especifican en el diseño

● Práctica común:

- nombre del atributo = papel en la relación


Paso de mensajes

● Mensaje: nombre + argumentos

● Un mensaje invoca una operación

- Cada operación se corresponde con un método

- Distintos objetos implementan la operación mediante métodos con implementaciones distintas

- En general, los mensajes son síncronos

- Los LOO implementan el paso de mensajes como llamadas a función


Diagrama de secuencia

● Secuencia temporal de envío de mensajes

- Muestra un caso concreto


Agregación y composición (i)

● Relación “es_parte_de”

- Jerarquía todo / parte

- Permite la creación de estructuras complejas

- El objeto base delega en sus agregados

● Composición vs. agregación

- “es_parte_de” completo / incompleto

- Tiempo de vida vinculado

● Implementación: equivalente asociaciones


Agregación y composición (ii)


Generalización (i)

● Relación “es_un”

- Jerarquía generalización / especialización

- Permite la herencia entre clases

- Jerarquía de clases. Superclases, subclases

Las clases hijas heredan atributos y métodos de la clase padre y ancestros.

Pueden redefinir y añadir atributos y métodos.


Generalización (ii)

● Especialización

- Un objeto de la clase hija puede usarse en los mismos lugares que un objeto de la clase padre, pero no viceversa

- Punto de extensión

● Generalización

- Las clases hija heredan de las clases ancestros

- Factorizan elementos de diseño e implementación


Herencia Simple vs. Múltiple

● Simple: una única superclase

● Múltiple: varias superclases

● Problemas de la herencia múltiple

- Herencia repetida● Heredar de dos clases con el mismo ancestro

- Conflicto de nombres● Heredar de dos clases con atributos o métodos con el mismo

nombre


Problemas de la Herencia Múltiple


Herencia (i)

● Evolución del ejemplo:


Herencia (ii)

Cuidado: no romper la encapsulación


Herencia (iii)

● Problema: interface de CartaRol


Herencia (iv)

La interface de la raíz es la parte visible a los clientes de la jerarquía


Herencia (v)


Herencia (vi)

● Las relaciones también se heredan


Clase abstracta

● Clase que no tiene instancias

● Puede tener métodos sin implementar

● Permite

- Definir interfaces comunes para las subclases

- Factorizar atributos y métodos comunes

● Clase concreta

- No abstracta, puede tener instancias

- Debe implementar los métodos abstractos heredados


Clase abstracta (ii)


Clase abstracta (iii)


Generalización vs. Agregación (i)

● Generalización

- Usa la herencia

- Estática, en tiempo de diseño

- Basado en el concepto de clase

- La herencia es implícita

- Relación es_un

● Agregación

- Usa la delegación

- Dinámica, en tiempo de ejecución

- Independiente del concepto de clase

- La delegación es explícita

- Relación es_parte_de


Generalización vs. Agregación (ii)

● Delegación vs. herencia


Generalización vs. Agregación (iii)

vs.


Generalización vs. Agregación (iv)

vs.


Interfaces (i)

● Declaración de métodos públicos

● También elemento de OO

● Caso extremo de clase abstracta

- Sin atributos

- Todos los métodos abstractos


Interfaces (ii)

● Una clase realiza una interface

- Similar a la especialización

- Si no es abstracta debe implementar todos los métodos definidos en la interface

● Una clase puede implementar múltiples interfaces

- Alternativa a la herencia múltiple

- Permite mayor flexibilidad en diseños complejos


Interfaces (iii)


Tipos y subtipos (i)

● Clases e Interfaces definen tipos

- Especialización y realización crean subtipos

- Si B es un subtipo de A● La interface de un objeto de tipo B contiene la interface

definida en el tipo A● Un objeto de tipo B puede representar los mismos papeles

que un objeto de tipo A, pero no viceversa

● Polimorfismo

- Un subtipo puede redefinir métodos

- Un objeto puede realizar varios tipos


Tipos y subtipos (ii)

● Polimorfismo en Lenguajes OO

- Precisan dynamic dispatch● La selección del método sólo se puede resolver en tiempo de

ejecución

- Ejemplo (diagrama de clases Baraja/Carta):

Carta cc = new NaipeEspañol()c.nombre()c = new CartaRol()c.nombre()

método(c:Carta) c.nombre()


Sobrecarga

● Otra forma de polimorfismo

● Métodos con el mismo nombre y distinta firma

● En general es considerado pernicioso

- Mismo nombre para distintas operaciones


Dependencia

● Relación “débil” entre clases. Expresa:

- Uso como parámetro, resultado

- Instanciación


Constructores, destructores

● Constructor

- Se ejecuta tras crear un objeto

- Inicializa el estado del objeto

- Puede tener argumentos

● Destructor

- Se ejecuta antes de eliminar una instancia

- Libera recursos


Referencias

● Referencia a objetos

- Independiente de la localización en memoria

- Un objeto puede tener múltiples referencias

- En LOO, las variables contienen referencias

Carta c1Carta c2c1 = new NaipeEspañol()c2 = c1c1 = new NaipeEspañol()


Garbage collector

● Gestión de memoria explícita

- C++

● Gestión de memoria implícita

- javascript, java, ruby, ...

- Garbage collector


Metaclases

● Metaclases

- Las clases son ciudadanos de primer orden

- Objetos que representan clases

- Introspección

Introducción a la Orientación a Objetos -...

Documents

Transcript of Introducción a la Orientación a Objetos -...