4.- Orientación a Objetos Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA.

Presentación del tema: "4.- Orientación a Objetos Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA."— Transcripción de la presentación:

1 4.- Orientación a Objetos Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

2 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Índice La abstracción de los hechos La interfaz: esa gran desconocida Encapsulamiento Herencia Reutilización Tipos de relaciones Polimorfismo

3 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) La abstracción de los hechos El programador ha de establecer una relación entre la máquina en la cual se está resolviendo el problema y el modelo de conocimiento del cual procede; es decir, entre el espacio de soluciones y el espacio de problemas. La orientación a objetos provee al desarrollador la capacidad de representar elementos en el espacio de problemas. Estos elementos se denominan “objetos”. Smalltalk, C++, Java,... son tipos más o menos puristas de OOL (Object-oriented languages).

4 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Características de OOLs 1. Todo es un objeto 2. La comunicación entre objetos se realiza mediante paso de mensajes. 3. Todo objeto está construido por otros objetos internamente. 4. Todo objeto tiene un tipo O, utilizando otra manera de hablar, toda instancia proviene de una clase. 5. Todo objeto del mismo tipo puede recibir los mismos mensajes. Si un objeto del tipo “pastor aleman” es también del tipo “perro”, ambos podrán aceptar mensajes del tipo “ladra”.

5 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Interfaz: esa gran desconocida Desde la filosofía antigua se viene hablando de “tipos” o “clases” –tipo de pájaro, clase de pez-. Todos los objetos, aunque son únicos, comparten características comunes. Realmente, podríamos hablar de un árbol – aunque como veremos, también se podría tratar de un grafo-.

6 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Interfaz: esa gran desconocida (II) En la programación OO, es vital la obtención de “clases”: tipos abstractos de datos. A partir de esas clases se pueden obtener “variables” (denominadas “instancias” en la jerga OO). Y comunicarlas mediante el paso de mensajes. Cada instancia es idéntica a su hermana, pero cada una mantiene su propio estado. TV::Grundig TV::Thomson TV

7 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Interfaz: esa gran desconocida (III) Pero, ¿cómo conseguimos que los objetos trabajen? Cada objeto ha de satisfacer un conjunto de peticiones que se le puedan realizar. P.e. Un objeto “bombilla” (“light” en el dibujo): El conjunto de peticiones que se pueden realizar sobre el objeto se encuentra definido por su INTERFAZ. El tipo (o clase) es lo que determina la interfaz.

8 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Interfaz: esa gran desconocida (y IV) Así que la interfaz ofrece al exterior el comportamiento del objeto. Por otra parte, el código que satisface esa petición, así como datos u operaciones internas, conforman la IMPLEMENTACIÓN del objeto. Del ejemplo anterior: Light lt = new Light(); lt.on(); Así que, importante para el futuro: Un objeto de un tipo (clase) determinado comprende: Interfaz: qué se ofrece. Implementación: cómo se ofrece.

9 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Encapsulamiento Una de las características de los sistemas distribuidos –pero que es aplicable a cualquier otro sistema- es la Apertura: Permite a un SO expandirse en múltiples direcciones. La apertura se consigue especificando y documentando las interfaces fundamentales del sistema y poniéndolos disponibles a los desarrolladores, para, finalmente, estandarizar esas interfaces: las interfaces de las clases que conforman el API se hacen públicas Para ello hay que exponer al usuario sólo aquellas operaciones que se establezcan como públicas. Facilidad de utilización. Posibilidad de errores por programadores inexpertos. Java utiliza tres palabras clave: public, protected, private – aparte, existe otro estado por defecto-. Se explicará más adelante.

10 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Herencia Sería un inconveniente tener que crear nuevas clases muy parecidas a otras que ya existían. El concepto de Herencia nos permite crear “clones” o “hijos” de clases, de tal forma que heredan su estado. A esta clase hija se le puede añadir o modificar funcionalidad con respecto a la del padre. ¡La interfaz se duplica!

11 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Herencia (y II) Opciones de utilización de la herencia 1.<= Añadir funcionalidad 2. Modificación de comportamiento =>

12 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Reutilización La reutilización de código es una de las grandes ventajas de la OO. No es fácil de obtener –parece fácil al principio...- Técnicas de reutilización: Utilización directa. La misma clase vale. Subclassing: heredar una clase (frameworks). Modificación de una clase existente: 

13 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Tipo de relaciones 1. Ya conocido: Herencia 2. Agregación Dentro de una objeto puede albergarse un conjunto de instancias de diferentes clases que conformen parte del estado del primero. Composición: especialización de la agregación. “Has-a”.

14 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Polimorfismo “Early binding”. Linker => dirección absoluta. En OOP eso no se puede hacer hasta run-time: late- binding. Controlador de pájaros.

15 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Polimorfismo (II) Operación del BirdController: hazAlgo(Bird b) { b.move(); } Y en otra parte del código: Goose g = new Goose(); Penguin p = new Penguin(); hazAlgo(g); hazAlgo(p); ¿Y si ahora añadimos un tipo “Tweety” descendiente de Bird sin método “move” sobrecargado? Tweety t = new Tweety(); hazAlgo(t);

16 Escuela Politécnica Superior de Ingeniería Departamento de Ingeniería Informática (DII) Polimorfismo (y III) Si “Bird” o “Shape” nunca van a ser instanciables, es mejor declararlas como clases abstractas o virtuales puras. También las operaciones –métodos- pueden ser abstractas: Sólo dentro de clases abstractas. Obliga a las subclases a implementar ese método. signatures Otra opción es definir directamente “interfaces”: se pueden entender como clases abstractas sin implementación alguna, sólo signatures (¿nos suena de algo?)