Introducción a la Orientación a Objetos -...
Transcript of Introducción a la Orientación a Objetos -...
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
© David Cabrero Grupo MADS - UDC 3
Metodologías y OO
● Presente en todas las fases de la metodología de desarrollo:
Diseño
Implementación
Validación
Mantenimiento
Análisis
© David Cabrero Grupo MADS - UDC 4
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)
© David Cabrero Grupo MADS - UDC 5
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
© David Cabrero Grupo MADS - UDC 6
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()
© David Cabrero Grupo MADS - UDC 7
OO y Paso de Mensajes (ii)
● Paso de mensajes
- 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
© David Cabrero Grupo MADS - UDC 8
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)
© David Cabrero Grupo MADS - UDC 9
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
© David Cabrero Grupo MADS - UDC 10
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)
© David Cabrero Grupo MADS - UDC 11
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
© David Cabrero Grupo MADS - UDC 12
Introducción a UML (iii)
● Herramientas de UML
- Papel y lápiz
- Software de dibujo especializado
- Herramienta integrada en un entorno de desarrollo
© David Cabrero Grupo MADS - UDC 13
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]
© David Cabrero Grupo MADS - UDC 14
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
© David Cabrero Grupo MADS - UDC 15
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
- items = [“abc”,”foo”,”bar”]- last = 3- it = 2
© David Cabrero Grupo MADS - UDC 16
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
+ añadir(item:string)+ borrar(item:string)+ elemento_en(i:int):string+ siguiente():string
unaLista
- items = [“abc”,”foo”,”bar”]- last = 3- it = 2
+ añadir(item:string)+ borrar(item:string)+ elemento_en(i:int):string+ siguiente():string
© David Cabrero Grupo MADS - UDC 17
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
© David Cabrero Grupo MADS - UDC 18
Resumen
● OO cubre el ciclo de desarrollo completo
● Características:
- Abstracción
- Encapsulación
● Paso de mensajes
● UML
● Objeto
- Encapsula:● Atributos● Métodos
- Propiedades:● Estado● Identidad● Comportamiento● Tiempo de vida
© David Cabrero Grupo MADS - UDC 19
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
© David Cabrero Grupo MADS - UDC 20
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]
© David Cabrero Grupo MADS - UDC 21
Especificación de una clase
● Definición de una clase:
- Nombre de la clase
- Lista de atributos
- Lista de métodos
© David Cabrero Grupo MADS - UDC 22
Clases. Problemas de diseño
● No Bajo acoplamiento
● Clases sin métodos
© David Cabrero Grupo MADS - UDC 23
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)
© David Cabrero Grupo MADS - UDC 24
Visibilidad (ii)
● Ámbitos especiales:
- Protegido (#)
- Paquete (~)
● Solucionan problemas de implementación, no de diseño
© David Cabrero Grupo MADS - UDC 25
Instanciación
● Crear un objeto (instancia) a partir de la definición de una clase
© David Cabrero Grupo MADS - UDC 26
Clases. Convenciones
● Nombres de las clases
- Guía de estilo. P.e. CamelCase
- Singular
- Sustantivos
● Nombres de los atributos
- Privados comenzando por subrayado “_”
© David Cabrero Grupo MADS - UDC 27
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.
© David Cabrero Grupo MADS - UDC 28
Paquetes (ii)
● Estereotipos y relaciones entre paquetes
© David Cabrero Grupo MADS - UDC 29
Relaciones (i)
● Permiten
- Intercambio de mensajes
- Composiciones complejas de objetos
● Tipos de relaciones
- Dependencia
- Generalización
- Asociación
- Agregación / composición
© David Cabrero Grupo MADS - UDC 30
Relaciones (ii)
● Datos de una relación
- Cardinalidad
- Navegabilidad
- Restricciones
© David Cabrero Grupo MADS - UDC 31
Asociación
● Relación de tipo general
© David Cabrero Grupo MADS - UDC 32
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
© David Cabrero Grupo MADS - UDC 33
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
© David Cabrero Grupo MADS - UDC 34
Diagrama de secuencia
● Secuencia temporal de envío de mensajes
- Muestra un caso concreto
© David Cabrero Grupo MADS - UDC 35
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
© David Cabrero Grupo MADS - UDC 36
Agregación y composición (ii)
© David Cabrero Grupo MADS - UDC 37
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.
© David Cabrero Grupo MADS - UDC 38
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
© David Cabrero Grupo MADS - UDC 39
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
© David Cabrero Grupo MADS - UDC 40
Problemas de la Herencia Múltiple
© David Cabrero Grupo MADS - UDC 41
Herencia (i)
● Evolución del ejemplo:
© David Cabrero Grupo MADS - UDC 42
Herencia (ii)
Cuidado: no romper la encapsulación
© David Cabrero Grupo MADS - UDC 43
Herencia (iii)
● Problema: interface de CartaRol
© David Cabrero Grupo MADS - UDC 44
Herencia (iv)
La interface de la raíz es la parte visible a los clientes de la jerarquía
© David Cabrero Grupo MADS - UDC 45
Herencia (v)
© David Cabrero Grupo MADS - UDC 46
Herencia (vi)
● Las relaciones también se heredan
© David Cabrero Grupo MADS - UDC 47
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
© David Cabrero Grupo MADS - UDC 48
Clase abstracta (ii)
© David Cabrero Grupo MADS - UDC 49
Clase abstracta (iii)
© David Cabrero Grupo MADS - UDC 50
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
© David Cabrero Grupo MADS - UDC 51
Generalización vs. Agregación (ii)
● Delegación vs. herencia
© David Cabrero Grupo MADS - UDC 52
Generalización vs. Agregación (iii)
vs.
© David Cabrero Grupo MADS - UDC 53
Generalización vs. Agregación (iv)
vs.
© David Cabrero Grupo MADS - UDC 54
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
© David Cabrero Grupo MADS - UDC 55
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
© David Cabrero Grupo MADS - UDC 56
Interfaces (iii)
© David Cabrero Grupo MADS - UDC 57
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
© David Cabrero Grupo MADS - UDC 58
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()
© David Cabrero Grupo MADS - UDC 59
Sobrecarga
● Otra forma de polimorfismo
● Métodos con el mismo nombre y distinta firma
● En general es considerado pernicioso
- Mismo nombre para distintas operaciones
© David Cabrero Grupo MADS - UDC 60
Dependencia
● Relación “débil” entre clases. Expresa:
- Uso como parámetro, resultado
- Instanciación
© David Cabrero Grupo MADS - UDC 61
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
© David Cabrero Grupo MADS - UDC 62
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()
© David Cabrero Grupo MADS - UDC 63
Garbage collector
● Gestión de memoria explícita
- C++
● Gestión de memoria implícita
- javascript, java, ruby, ...
- Garbage collector
© David Cabrero Grupo MADS - UDC 64
Metaclases
● Metaclases
- Las clases son ciudadanos de primer orden
- Objetos que representan clases
- Introspección