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

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

2. Índice • La abstracción de los hechos • La interfaz: esa gran desconocida • Encapsulamiento • Herencia • Reutilización • Tipos de relaciones • Polimorfismo

3. 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. Características de OOLs • Todo es un objeto • La comunicación entre objetos se realiza mediante paso de mensajes. • Todo objeto está construido por otros objetos internamente. • Todo objeto tiene un tipo • O, utilizando otra manera de hablar, toda instancia proviene de una clase. • 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. 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. 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 TV::Grundig TV::Thomson

7. 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. 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. 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. 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. Herencia (y II) • Opciones de utilización de la herencia • <= Añadir funcionalidad 2. Modificación de comportamiento =>

12. 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. 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. Polimorfismo • “Early binding”. • Linker => dirección absoluta. • En OOP eso no se puede hacer hasta run-time: late-binding. • Controlador de pájaros.

15. 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. 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. • Otra opción es definir directamente “interfaces”: se pueden entender como clases abstractas sin implementación alguna, sólo signatures (¿nos suena de algo?)