2025-02-24-Programacion | Mediateca de EducaMadrid

Inicia la grabación, la semana pasada después de hacer la grabación la subí a la mediateca que es desde donde las comparto y de forma inmediata no está disponible la mediateca, como que la tienen que cocinar allí de alguna forma, no sé. 00:00:00

y luego ya por la noche suele estar disponible para poder utilizarla o al día siguiente 00:00:16

y se me pasa dos o tres días hasta que bueno, uno de los que creo que andáis por aquí 00:00:21

el que me pusisteis el mensajillo, si me vuelve a pasar pues avisarme 00:00:25

que es que se me olvidó poner el enlace en la ola virtual para que la vierais 00:00:29

luego deciros también que la semana que viene, bueno tanto el viernes 00:00:33

no sé si tenéis alguna tutoría, como luego el lunes son días no lectivos 00:00:39

Es verdad que no son festivos los dos, me parece, para los trabajos, pero sí que son no lectivos, con lo cual esos dos días no tendréis tutorías. Si tenéis alguna el viernes, no contéis con ella y, bueno, pues el lunes, este lunes que viene, no tendremos clase como todos los lunes habitualmente. 00:00:43

de tal forma que creo que el siguiente tema, el tema 8 00:01:01

abre el martes de la semana que viene, como lo tenemos 00:01:08

estipulados así en martes, con lo cual en principio hoy es el último 00:01:12

día que tenemos del tema 7 y luego una vez cerrado el tema 00:01:16

sabéis que siempre solemos dedicar, si no hay ninguna petición 00:01:20

particular, solemos dedicar la tutoría siguiente a resolver la tarea 00:01:24

es decir, tenemos en principio para el tema 7 00:01:28

Si luego es necesario echar un ratillo por ahí alguna otra tutoría con alguna cosa, pues lo buscaríamos el día de hoy para pegar un pequeño repaso de lo que vaya surgiendo por aquí del tema 7. 00:01:32

Tengo por aquí un guión para iros contando algunas cosas y luego, no el lunes que viene, sino en 14 días haríamos la tarea. 00:01:43

Y bueno, en base a la tarea ya sabéis que vamos siempre muy despacito, de tal forma que volvemos a repasar un poco de nuevo todos los conceptos. 00:01:51

Y bueno, antes de empezar a contaros, como siempre, preguntaros si tenéis alguna cosilla, alguna aclaración que queráis que hagamos de alguna cosa de las que estáis viendo o de algún aspecto por ahí que queráis comentar. Bueno, sí, podemos, pues lo alargamos, no sé. Estás, bueno, para que quede grabado me proponen alargar un poquito más la tarea. No sé, podríamos, podría ser un par de días. ¿Pensabas en un par de días o en tres días o en cuánto tiempo estabas pensando hacer la propuesta de alargarla? 00:01:59

Bueno, pues nada, si al fin y al cabo las tutorías es para que las podáis trabajar y si me comentáis que en principio os ha pillado un poco el toro, en este caso a ti, para hacerla, pues bueno, la pospongo una semana y ya está. 00:02:45

vale 00:03:19

vale, pues nada 00:03:30

pues 00:03:35

los plazos para ir abriendo temas 00:03:36

los mantenemos, pero lo que es 00:03:40

la posibilidad de entrega de la tarea, pues en lugar 00:03:42

de cerrar el próximo 00:03:44

lunes, que sería, pues lo 00:03:45

dejamos para cerrar una semana después 00:03:48

y ya está, vale, pues ya está 00:03:49

lo hago así, luego os pongo también 00:03:51

si no se me olvida, os pongo 00:03:53

un mensajillo para que lo sepa todo el mundo 00:03:55

que no esté 00:03:58

que no vea la tutoría o que no esté 00:03:59

ahora aquí o no la había luego grabada y ya está, que sepan que la alargamos una semana 00:04:01

y ya está, vale, sí, sin problema. Vale, pues nada, si 00:04:06

no hay más cosillas por ahí, pues os empiezo a contar un poco 00:04:12

algunas cosas que tengo por aquí apuntadas de guión que 00:04:17

he sacado de lo que es la teoría de este tema. En realidad 00:04:21

muchas de ellas, es verdad que es un tema extenso, pero muchas de ellas 00:04:25

las hemos ido hablando durante el curso, así que bueno, si ya tenemos 00:04:29

un poco base de algunos conceptos, pues bienvenido sea. 00:04:33

Vamos a crear un proyecto y vamos hablando 00:04:37

de los diferentes conceptos teóricos que aparecen 00:04:41

por ahí. Vamos a poner aquí tema 7 00:04:45

para el proyecto. Este tema, en principio, 00:04:48

arranca hablando de lo que son las relaciones entre diferentes 00:05:00

clases que nos podemos encontrar en un proyecto. 00:05:04

y bueno, a grandes rasgos, ya os digo que hemos hablado 00:05:06

de las relaciones que podemos tener, tenemos dos 00:05:10

una, que podemos tener 00:05:13

definida una clase y ser un atributo 00:05:16

de otra, vamos a ponernos en la situación 00:05:19

de una persona y de la clase persona 00:05:22

y de la clase brazo 00:05:25

podemos entender que una persona está formada 00:05:26

por cabeza, tronco y extremidades 00:05:31

podríamos definir una clase tronco que tuviera sus propios 00:05:33

atributos como clase en sí o los objetos que podamos definir 00:05:38

de ella y sus métodos, como siempre, como toda clase 00:05:42

y luego en sí, cuando definimos la clase 00:05:46

persona, si está formada por cabeza, tronco y extremidades 00:05:50

el tronco sería uno de los posibles atributos de la clase 00:05:53

persona. Entonces esto es uno de los tipos de relación que principalmente 00:05:58

existen. Y luego, el otro tipo de relación es el de herencia. 00:06:02

Bueno, ahora hablamos también 00:06:09

de un tercer tipo que aparece ahí en la teoría. 00:06:10

Pero vamos, como dos grandes relaciones entre clases, esta, que una 00:06:14

clase sea atributo de otra. Ahora hacemos un ejemplillo donde aparezca, 00:06:18

aunque ya hemos trabajado con ella en algún momento. Por ejemplo, en la tarea 00:06:22

esta de cocina, pues la cocina tenía como 00:06:26

clase integrada en forma de atributo de la clase cocina 00:06:30

tenía el frigorífico y tenía la placa, ¿no? Pues esa está la idea. 00:06:34

Y luego tenemos la posibilidad de herencia, que es una de las 00:06:38

características de la programación orientada a objetos, en alguna otra tutoría hemos hablado ya 00:06:42

de ello, y lo que hacemos es que las clases hijas 00:06:46

de la clase, hay una estructura en árbol, digamos, de clases 00:06:50

cuanto más arriba estás, pues digamos que las clases 00:06:54

que están por encima de las que están por debajo actúan de clases padre de las clases que están 00:06:58

por abajo entonces las clases que están por abajo en esta estructura heredan características de la 00:07:02

clase padre básicamente heredan sus atributos y sus métodos los que tienen disponibles y luego 00:07:08

bueno pues está la otra de las características de la programación orientada a objetos que es la 00:07:17

sobrescritura que podemos sobre escribir el comportamiento que tiene heredado de un método 00:07:21

por ejemplo, de la clase padre, lo podemos sobrescribir en la clase hijo para que sea la que considera. 00:07:25

La primera, en la que son atributos una clase de otra, en la teoría la refiere como composición 00:07:33

y la mete dentro de una categoría de tipos de clase de uso de clientela. 00:07:43

Es como aparece ahí en la teoría. 00:07:49

Y dentro de estar del uso de clientela, también tenemos la posibilidad de anidamiento. 00:07:51

Y el anidamiento es que dentro, no que tenemos un objeto o una referencia de una clase como atributo de otra, sino que la definición de la propia clase está dentro, una clase está dentro de otra en su código. 00:07:56

Pues en una clase podemos tener, imaginaos la clase Persona, de la que hablábamos antes, pues tendríamos sus atributos, tendríamos sus métodos y además de sus atributos y sus métodos podríamos tener definida una clase dentro de la clase Persona. 00:08:12

Pues esto es lo que es el anidamiento. Bueno, yo lo uso poco, en verdad, la idea viene relacionada, la idea de anidar unas clases con otras, que también en la teoría aparece como uso de tipo clientela, tiene que ver con cuestiones de encasulamiento, que es otra de las características que tenemos en la programación orientada a objetos. 00:08:30

típicamente si nosotros tenemos un programa 00:08:54

ahora llegamos a las clases 00:08:59

sanidadas, pero si tenemos un programa con diferentes clases 00:09:02

para acceder desde unas clases a otras, lo hacemos bien 00:09:05

si la visibilidad lo permite, bien accediendo directamente 00:09:09

a sus atributos o bien a través de métodos también en función de la visibilidad 00:09:14

si es público, privada, PACAS, os acordáis de todo esto 00:09:18

Entonces, esta forma de acceder a las características y a las acciones que puedan hacer los objetos de una determinada clase a través de sus atributos y sus métodos, llamándolos, para que una clase externa sea capaz de trabajar con ello, necesita conocer su protocolo. 00:09:21

¿Cómo puedo yo comunicar con un objeto de esta clase o su protocolo o su interfaz? ¿Qué interfaz me da la clase persona de cara al resto del programa? Pues hay un método que será el método saludar, otro que será el método despedir y un atributo para la persona que sea el nombre y la edad. Pues ese es el interfaz, la cara que da un objeto de la clase persona hacia el resto del programa. 00:09:44

como imaginaos que dentro de la clase persona se puede consultar el dni verdad con un getter 00:10:06

del atributo dni o directamente con un método que te devuelve el número del dni que tiene esa 00:10:16

persona pues resulta que en la estructura del programa en general nosotros desde cualquier 00:10:23

clase podríamos poner haber instanciado un objeto de la clase persona que sea no a poner 00:10:29

noa.getDNI, el getter del DNI y me daría el número o el string que tiene el DNI. 00:10:35

Pero desde fuera nos despreocupamos por completo de cómo el getter de la clase persona ha obtenido ese DNI. 00:10:43

Imaginaros que en un momento dado podría estar en una base de datos, no sé si habéis estudiado el módulo de base de datos 00:10:52

y hacer un select a una tabla, o podría estar en un fichero o directamente desde el getter con un escáner 00:10:58

se podría pedir desde teclado. La implementación del getter está encerradita dentro de la clase persona y a quien quiera utilizar el método getter de la clase 00:11:05

persona le es ajeno por completo porque lo único que hace es llamar a través de un método que es el getedad de la clase persona le es ajeno si en realidad de la clase 00:11:18

persona se ha obtenido ese dato accediendo a una base de datos a un 00:11:29

fichero por teclado o se lo ha inventado directamente con 00:11:32

un DNI aleatorio. Él solamente conoce el interfaz 00:11:37

y sabe de la clase persona, desde una clase externa 00:11:41

a la persona y sabe que para tener el DNI de un objeto de la clase persona 00:11:45

utiliza el getter y ya está. En cambio, el desarrollo 00:11:48

puede estar montado de una forma u otra. Imaginaos que este getter 00:11:52

estuviera haciendo un select a una base de datos 00:11:56

para devolvernos el DNI. 00:11:59

Pues estupendo, la clase externa de mi programa 00:12:00

utiliza el getter, pero mañana de repente 00:12:03

se hace una actualización del programa 00:12:07

y alguien me va a preguntar algo 00:12:09

un segundo en que termino de desarrollar esto 00:12:12

y te doy la palabra. 00:12:14

Una persona, o sea, de repente 00:12:17

a nivel de desarrollo se decide 00:12:19

que se va a quitar la base de datos 00:12:23

y esa información se va a volcar a un fichero. 00:12:24

Simplemente tendríamos que trabajar sobre el código del método getter de la clase persona, pero el resto del programa seguiría funcionando de igual forma, porque el interfaz se mantiene y seguiríamos obteniendo esa información a través del getter. 00:12:26

Esto es lo que nos permite trabajar desde fuera con interfaces y utilizar la característica de abstracción, es decir, que la información está ahí, es indiferente a nosotros cómo se tiene esa información porque nosotros trabajamos desde otras clases a través de interfaces o protocolos de acceso a las clases. 00:12:39

si, alguien me quería preguntar algo por ahí 00:13:00

o ha levantado la mano, no sé si por error 00:13:03

un mensaje al chat, a ver, vamos a ver 00:13:05

no, solo estoy contando de momento, no me he puesto a escribir 00:13:15

nada de momento, no, era por si teníais duda 00:13:23

si estaba escribiendo, no, simplemente os estoy contando, ahora arrancamos 00:13:26

a hacerlo, entonces pues nada 00:13:29

el interfaz, las tracciones son las características 00:13:33

de la programación como os digo orientada a objetos 00:13:37

y consiste en esto, entonces 00:13:39

El anidamiento, que es una forma de relacionar diferentes clases, es meter una clase dentro de otra y típicamente cuando trabajas con anidación, pues imaginaos que estás con la clase tronco y dentro del tronco, de forma anidada, dentro de la clase tronco define la clase corazón. 00:13:43

Pero no la defines como una clase fuera y tienes un atributo, sino que la defines dentro. Es un poco como bajo el concepto general de a la clase corazón no se va a acceder desde ningún sitio que no sea la clase tronco. 00:14:01

Con lo cual me puedo permitir dejarla ahí muy encerradita dentro de la clase tronco porque no va a haber ningún acceso por ahí externo. Es un poco esa la idea. Entonces la anido dentro de la tronco y lo dejo ahí muy encasulado para que esté muy muy encerradito con la idea esa de hago todo el desarrollo del tronco y cuando necesite un servicio del corazón internamente ahí lo tengo encerradito el código y no está accesible desde otras partes de los programas. 00:14:16

En lugar de tenerla anidada, la podríamos tener en una clase diferente, probablemente privada, o sea, probablemente que solamente fuera accesible desde el propio proyecto, desde el propio paquete y tenerla como un atributo. En ese caso se convertiría en una clase de composición. 00:14:43

Entonces esto es los dos usos generales, un uso de clientela que principalmente si dejamos a un lado el anidamiento es la composición, clase cocina que tenía como atributos frigorífico, luego incluso tuvimos un array de frigoríficos, un array de placas o herencia que hemos hablado en algún momento en alguna tutoría y hoy hacemos algún ejercicio también de herencia. 00:15:01

Vamos a ir desarrollando aquí algunas clases para ir apoyándonos en el código. 00:15:28

Vamos a definir la clase persona, vamos a definir la clase cabeza, vamos a definir la clase alumno, vamos a definir la clase profesor, por ejemplo. 00:15:37

y vamos a buscar relaciones un poco entre todas estas cosas. 00:16:09

Mirad, en la clase persona, a la hora de buscar una relación con cabeza, 00:16:20

pues entendemos que la cabeza es algo, es una parte de una persona. 00:16:30

Una cabeza pertenece a una persona. 00:16:36

En cambio, la clase alumno no es algo que pertenezca a una persona, sino que es un tipo de persona. Y profesor no es algo que pertenezca a una persona. Digamos que están un poco al mismo nivel una persona y un profesor. Un profesor no es una parte de una persona como sí que lo es una cabeza o lo es el tronco. 00:16:38

entonces a la hora de buscar una relación entre persona y estas otras clases 00:17:00

un poco la pregunta que nos podemos hacer es esto 00:17:05

queremos que la clase cabeza esté relacionada con la clase persona 00:17:08

si la consideráramos como una herencia 00:17:11

tendríamos que decir, ¿la cabeza es un tipo de persona? 00:17:14

si tenemos un concepto general de persona 00:17:19

¿un grupo de personas sería la cabeza? 00:17:22

pues no, no es un tipo de persona, es una parte de las personas 00:17:24

Entonces la relación que tenemos es de clientela, según dice la teoría, esto de clientela la verdad aparece en nuestra teoría, pero yo creo que no está luego mucho por ahí en textos, pero bueno, y lo que sería, sería una relación de composición, la cabeza es un tipo de, es una parte de las personas. 00:17:28

Entonces, podríamos decir que como atributo, perdón, aquí no, como atributo de la clase persona, pues resulta que tiene una cabeza. Luego también tendría ese nombre, pues esto sería un atributo, ¿verdad? 00:17:50

Este va a terminar siendo un objeto referenciado de la clase cabeza. Y el string, bueno, el string ya decimos que es referenciado, pero también tiene ciertas características de los tipos primitivos, porque no lo hacemos el new, pues sería otro atributo y en este caso basado en tipo string. 00:18:08

Y uno primitivo, puramente dicho, pues podría ser la edad. 00:18:27

No referenciado y primitivo. 00:18:33

Tiene tres atributos, la clase persona, una de ellas, ya que es una relación entre diferentes clases, 00:18:35

la clase cabeza y la clase persona, es que la cabeza es una parte de la persona, 00:18:40

con lo cual hacemos una relación de composición. 00:18:45

En cambio, pegaría aquí poner alumno, lógicamente se lo va a tragar, ¿no? 00:18:51

porque es una clase que existe, a nivel de Java se lo traga, pero a nivel de conceptual 00:18:58

podríamos decir que un alumno es una característica 00:19:02

de una persona, pues no, más bien es un tipo de persona 00:19:06

lo que haríamos sería decir que si es un tipo de persona 00:19:10

y tenemos una jerarquía, un orden de clases de arriba abajo, podríamos decir 00:19:14

pues tenemos las personas que pueden ser de tipo 00:19:18

alumno o de tipo profesor 00:19:23

Y las personas, esto sería una relación de herencia. ¿Un alumno es un tipo de persona? Sí. ¿Un profesor es un tipo de persona? Sí. ¿Un alumno podrá hacer cosas o tendrá características típicas de las personas? Pues sí. 00:19:27

Fijaros en la clase alumno, podríamos coger y decir, ¿los alumnos tienen como relación de composición una cabeza? Pues sí, podríamos coger y definir aquí que tienen una cabeza. Sería correcto como atributo de clase de la clase alumno. 00:19:44

Pero lo que vamos a hacer va a ser aprovechar otra relación entre clases que es la de herencia para decir, definimos que toda persona tiene una cabeza, un alumno que es un tipo de persona la haremos hija de la clase persona y como hereda todos sus atributos directamente como herencia ya obtendrá el atributo de CAP de tipo cabeza como herencia de la clase persona. 00:20:03

Un poco la estructura podría ser esta, por herencia de arriba abajo y aquí podríamos decir los atributos que tiene una persona, que sería el nombre, en este caso la edad y en principio que tiene una cabeza, también podríamos decir una clase que fuese de tipo, de otros tipos, de tronco y extremidades, como fuera para piernas y todo esto. 00:20:33

En la teoría creo que habla también de un ave a la hora de explicar esto. Entonces dice, vamos a considerar la clase ave y la clase loro. Entonces podríamos decir, ¿un loro es una característica de un ave o es un tipo de ave? 00:20:54

más bien un tipo de ave, pues la respuesta que nos da la relación entre 00:21:19

ave y loro es que es un tipo de, pues entonces la relación 00:21:24

podría ser de herencia, y luego habrá por ejemplo de la clase 00:21:28

pico y alas, un pico es un tipo 00:21:32

de ave o es una característica que tienen las aves 00:21:36

pues si es una característica que tienen las aves, en este caso sería una relación de composición 00:21:40

esta es un poco la idea 00:21:44

Bien, fijaros, si tenemos la clase persona por aquí, entonces hemos utilizado una referencia, que no todavía una cabeza, porque para que exista la estructura de cabeza, sabéis que tendríamos que hacer el new, una referencia, es decir, a este logo le tendremos que hacer en algún momento un new para poder utilizar esta referencia a la cabeza. 00:21:48

Y en cuanto a la relación de herencia, lo que haríamos sería para indicar que una clase es hija de otra, que en principio es la clase padre, es decir, que el alumno va a heredar cosas de la clase persona, que es la padre. 00:22:08

la etiqueta que utilizamos es Stents. 00:22:24

Con Stents está la forma que tenemos de identificar 00:22:28

que un alumno en el código es un tipo de persona 00:22:33

y alumno será una clase que en esa estructura en árbol estará justo por debajo 00:22:37

de la clase persona. Y esta herencia, Stents 00:22:41

de persona, ya me garantiza que tengo disponibles 00:22:45

los atributos y métodos que están definidos 00:22:49

en la clase persona. 00:22:53

Imaginaos que tenemos aquí 00:22:56

pues yo que sé 00:22:57

public 00:22:59

voy a saludar 00:23:00

como siempre, siempre utilizamos los mismos métodos 00:23:02

la verdad para poner los ejemplos 00:23:05

ponemos aquí un hola 00:23:07

soy una persona 00:23:15

pues resulta que ahora 00:23:19

la clase alumno 00:23:21

por esta herencia 00:23:23

que estamos identificando aquí de la clase 00:23:25

persona 00:23:27

tiene estos atributos 00:23:28

y tiene un método disponible 00:23:33

mirad, si creamos aquí otra clase 00:23:37

por un momento 00:23:44

vamos a poner la clase humano, por ejemplo 00:23:47

podríamos decir también que un alumno 00:23:51

es 00:23:58

un tipo de humano, ¿verdad? 00:23:59

Y que un profesor es un tipo 00:24:03

de humano, viene a ser algo equivalente 00:24:05

a la clase persona. Entonces 00:24:07

podríamos estar tentados de coger y decir 00:24:09

fijaros, la clase 00:24:11

humano, pues un humano también podría 00:24:12

tener un nombre. 00:24:15

Y un humano 00:24:19

también podría saludar. Voy a hacer copia y pega 00:24:20

de este saludar. 00:24:23

Fijaros que el programa 00:24:34

me compila perfectamente. Bueno, pues si está en una clase humano 00:24:35

podríamos darle un nombre y podremos llamar al método saludar 00:24:38

de la misma forma que podemos hacerlo con la clase persona. 00:24:41

La clase alumno, dentro del diseño de nuestro programa, 00:24:45

hemos decidido que herede de persona. Pero podríamos decir 00:24:47

oye, un alumno, las características, imaginaos 00:24:50

que los alumnos, los humanos, yo que sé, 00:24:54

que deciros, pues tienen un método también aquí 00:24:57

que es el método respirar. 00:24:59

Lo hemos implementado justo 00:25:03

a ver, voy a ponerlo siguiendo el formato que tenemos con minúscula, que si no, así, pues en la clase humana resulta que también definimos el método respirar y aquí pondríamos el código correspondiente a la acción de respirar, el que estuviera definido en nuestro programa, código en Java para respirar. 00:25:05

Entonces podríamos decir, oye, si un alumno también es un humano 00:25:37

y me apetece tener disponible el método respirar que se ha definido en la clase humano, 00:25:41

entonces podríamos tener la tentación de coger aquí y decir, pues mira, 00:25:47

que herede de persona para heredar ciertas cosas y además herede de humano también para, 00:25:50

y así ya tengo la posibilidad de poder llamar al método respirar que lo tengo implementado en esta clase, 00:25:56

Ya que un alumno responde a esto de es un tipo de humano, pues esto no me deja, ¿verdad? Fijaros, dice que no le gusta esta coma, si quitamos la coma sigue sin gustarle y me dice por aquí que quite humano por aquí. 00:26:03

¿Cuál es el motivo? Pues que en algún lenguaje de programación sí que está permitido y bueno, y vete a saber cómo lo terminan gestionando, pero Java coge el criterio de decir que una clase no puede tener herencia múltiple. 00:26:22

La herencia es única y exclusivamente la que tengamos aquí definida de una clase padre solo. ¿Y cuál es el motivo que se argumenta? Pues el motivo que se argumenta es este, que una persona, la clase persona, tiene un método saludar donde sacaría un hola soy una persona y la clase humano está diciendo hola soy humano, el mismo método. 00:26:36

¿Qué sucede si hacemos una herencia múltiple de varias clases? Que si yo cojo y defino un objeto de la clase alumno y llamo al método saludar, por herencia, como él no lo tiene aquí escrito, por herencia intentaría localizar ese método saludar. 00:27:00

y resulta que tendría dos opciones y volveríamos a esas ambigüedades 00:27:16

que estamos ya acostumbrados a ver que Java no nos las acepta 00:27:21

porque diría, oye, si yo tengo un método saludar desde la clase persona 00:27:24

y un método saludar desde la clase humano, con esta ambigüedad, ¿cuál de los dos 00:27:28

utilizo? ¿Cómo lo resolvemos? Pues obligando 00:27:32

a que la herencia sea única. Si es única, ¿qué es lo que 00:27:36

pasa? Pues que ahora ya no hay ambigüedad. Si he decidido que herede la clase 00:27:40

persona y llamo al método saludar, me sacará este. Y si por el contrario he decidido que herede la clase 00:27:44

humano, fijaros como también me compila, también le vendría y llamo al método saludar, pues me saludará 00:27:51

como este sin amigudad ninguna. Con toda seguridad al heredar de humano diría hola soy un humano. 00:27:58

Bueno, esto lo enseño para argumentar que la herencia no puede ser múltiple. Leyendo la teoría, 00:28:06

Bueno, pues nos dice, y también lo he comentado yo alguna vez, que hay una herencia implícita, esta, bueno, aquí la ponemos de forma explícita de quién queremos heredar a través de la etiqueta stent, pero hay una herencia implícita, es decir, que toda clase disponible en Java siempre tiene un comportamiento de herencia desde la clase object. 00:28:15

que si tenemos, ya os digo, una estructura en árbol de padres, hijos, hijos, nietos, bisnietos 00:28:37

y todo esto es la que está arriba del todo, la clase object en Java. 00:28:44

Entonces, de esta clase object, características de esta clase heredan todas. 00:28:51

Todas las clases la tienen de forma implícita. 00:28:56

Es decir, eso de que solamente tenemos características heredadas desde una clase 00:28:59

que identificamos con la etiqueta stents es un poquito mentira 00:29:03

desde el momento en el que sí que tenemos 00:29:07

la posibilidad de utilizar cosas de forma heredada 00:29:09

desde la clase Object. Pero bueno, es 00:29:13

la clase Object y la que pongamos nosotros aquí. 00:29:16

Y no herencias a través de 00:29:20

más clases, pues, porque no 00:29:22

para que no se produzca esa situación que 00:29:24

hemos visto antes con el método saludar. 00:29:28

Y vamos a crear otra clase aquí que sea principal. 00:29:33

y en esta clase vamos a decir que meta el main 00:29:35

que yo creo que lo podemos identificar por aquí 00:29:44

aquí en Eclipse 00:29:45

aquí tenemos el main 00:29:47

de nuestro programa 00:29:51

entonces aquí podríamos coger y definir 00:29:53

un objeto de la clase alumno 00:29:56

mi alumno igual a new 00:29:59

alumno 00:30:05

como siempre el new para hacer la reserva del espacio de memoria 00:30:07

y llamamos a un constructor, como no hemos escrito 00:30:11

ninguno en la clase alumno, pues tiene uno por defecto 00:30:16

que es este, en cuanto escribamos uno el de por defecto desaparece y ya tenemos 00:30:20

que utilizar alguno de los definidos dentro de la clase 00:30:24

fijaros que la clase alumno la tenemos completamente vacía 00:30:27

aquí en cuanto a código, pero decimos que estamos heredando 00:30:32

vamos a poner de humano, vamos a poner de persona 00:30:36

humano lo había puesto, lo había creado para que vierais que no me dejaba 00:30:39

compilar con herencia múltiple 00:30:46

entonces como hereda de persona, aunque aquí no tengo nada definido, tiene heredado 00:30:48

todos los atributos y los métodos que tenga 00:30:54

la clase persona, entonces si yo pongo mi al punto aquí 00:30:58

punto, fijaros como me ofrece los atributos 00:31:04

que tiene la clase Persona. Fijaros, todos estos, Equals, GetClass, 00:31:07

HasCode, Notify, NotifyAll, Saludar, no, ToString, todos estos métodos, 00:31:12

¿por qué me los estará ofreciendo Eclipse para el objeto de la clase 00:31:17

alumno si no los tengo definidos aquí? Pues los estará recibiendo 00:31:22

a través de alguna herencia. En la herencia que tenemos aquí 00:31:26

identificada de la clase Persona, ¿tenemos definidos todos esos 00:31:29

métodos? No, solamente el método Saludar. ¿De dónde nos estarán 00:31:32

viniendo al resto de métodos de la clase object entonces cualquier objeto que pongáis tendrá estos 00:31:35

métodos ecuas get class has code notify notify all to stream por ejemplo to stream hemos hablado en 00:31:42

algún momento de que es convertir el ahora después trabajamos con él incluso convertir el objeto a 00:31:48

una cadena caracteres para que salga cuando llames al método y además este método es el que se llama 00:31:56

con el println de forma escondida. 00:32:01

Estos tienen que ver con gestión de hilos que estudiaréis 00:32:05

en la asignatura de programación de servicios y procesos el año que viene 00:32:09

probablemente. Todos estos otros métodos los tiene heredados 00:32:13

desde la clase object. En cualquier caso vamos a utilizar 00:32:17

el que tenemos identificado en la clase persona ahora inicialmente. 00:32:21

Entonces si ejecutamos 00:32:26

me dice hola soy una persona, ha utilizado el método 00:32:28

que él no tiene definido, pero en cambio 00:32:34

por herencia lo tiene disponible de la clase persona y precisamente 00:32:37

este código es el que nos ha mostrado aquí. Una de las características que 00:32:42

si cogemos y decimos que la clase profesor 00:32:49

también no es una 00:32:53

característica de una persona, un profesor, sino que es un tipo de 00:32:57

Y como es un tipo de persona, lo consideramos a través de la relación entre clases de herencia, pues la misma jugada de un profesor. Entonces, si cogemos aquí en el principal y ahora en lugar de definir un alumno, definimos un profesor. 00:33:01

tenemos el saludar también de forma heredada 00:33:20

y los dos efectivamente 00:33:34

llaman al mismo método, ninguno de los dos tiene definido el método saludar 00:33:39

los dos lo tienen disponible a través de herencia de la clase persona 00:33:43

con lo cual el código que ejecutan ambos dos para saludar es este 00:33:47

y nos sacan por pantalla hola soy una persona y aquí tenemos en la consola 00:33:51

como resultado dos veces el mensaje, una vez cuando ha saludado al alumno 00:33:55

y una segunda vez cuando ha saludado al profesor. 00:33:59

Bueno, pues está estupendo tener ese método, pero 00:34:03

resulta que puede ser que, digamos, mira, este 00:34:05

método me parece suficiente cuando saluda a un profesor, 00:34:10

pero me parece un poquito serio cuando saluda 00:34:15

a un alumno, que tiene a lo mejor un lenguaje un poquito más informal. 00:34:19

Pues, ¿qué podemos hacer en ese caso? Pues, podríamos coger, quitar la herencia directamente e implementar aquí el método saludar, pero si quitamos la herencia, perdemos este método porque lo queremos tener propio, pero también perderíamos estas características que pueden seguir interesándome en la clase alumno. 00:34:24

entonces podemos decir, oye mira, voy a mantenerme 00:34:43

efectivamente como una persona, voy a mantener la herencia de persona 00:34:46

porque me interesa de la clase persona estos atributos y otros 00:34:51

métodos más que pudiera tener por aquí, pero en cambio la forma de saludar 00:34:54

ya os digo que me parece un poquito seria para un alumno, pues 00:34:58

lo que puedo hacer es sobrescribir el método 00:35:02

saludar, cuando sobrescribimos el método saludar podemos poner 00:35:08

aquí una etiqueta, a ver si me acuerdo 00:35:13

como era, overwrite creo que es 00:35:16

si ponemos aquí una etiqueta overwrite 00:35:17

es decir, sobre escribiendo 00:35:25

o sobre escrito, y ponemos aquí un método 00:35:26

lo que estamos haciendo, si no aparece 00:35:29

el comportamiento en java es 00:35:31

el mismo, también nos funciona 00:35:33

ahora os cuento para que nos puede 00:35:35

en que nos puede ayudar poner esta etiqueta 00:35:37

en el código, entonces si yo 00:35:39

cojo ahora aquí dentro de la clase alumno y 00:35:41

sobre escribo 00:35:43

ponemos aquí hola qué tal así para que sea un poquito más informal como saluda el alumno yo 00:35:44

me vengo ahora ejecuto aquí y fijaros que como tengo sobre escrito en la propia clase el método 00:35:54

saludar en el momento que lo llamo antes de irse a buscar el método saludar que tiene disponible 00:36:00

por herencia desde la clase persona localiza a ver si tiene él un método saludar propio y si lo 00:36:06

tiene es el que utiliza. Entonces coge y llama al 00:36:12

método saludar propio y en cambio el profesor 00:36:16

que no ha implementado un método saludar, el único que tiene disponible es el de 00:36:20

por herencia desde la clase persona y por eso se mantiene aquí el mensaje 00:36:24

que nos mostraba el saludar de esta clase. 00:36:28

En cambio, el alumno muestra este otro. Esta es otra 00:36:32

de las características que tenemos en la programación orientada a objetos que es 00:36:36

la sobrescritura. 00:36:39

Si dentro de la clase persona, 00:36:52

imaginaos que, bueno, aquí simplemente es un mensaje 00:36:54

y estamos intentando que sustituya uno a otro, 00:36:56

pero imaginaos que, 00:36:59

bueno, imaginaos que, oye, pues 00:37:01

no es esto justo lo que quiero hacer, sino que 00:37:06

quiero utilizar el método saludar 00:37:08

de la clase persona, lo que tengan como 00:37:11

tal y como saluden las personas, pero además 00:37:12

de eso, quiero yo hacer más cosas aquí. Entonces, lo que 00:37:14

podemos hacer es sobreescribir el método y para que siga saludando como 00:37:18

la clase persona, podemos utilizar la etiqueta super. 00:37:22

Con la etiqueta super, lo que estamos diciendo es, llama al método 00:37:27

saludar, pero al método saludar de la clase padre. 00:37:30

Entonces, esto lo que ejecuta es el método saludar que tiene la clase padre 00:37:34

y luego como alumno, bueno, pues puedo hacer algunas cosas más. 00:37:38

lo que quisiera yo aquí con código Java. 00:37:42

Mejor escribir en una base de datos 00:37:47

cuando los alumnos saludan, aparte de mostrar el mensaje 00:37:50

hola, soy una persona, quiero que escriba en una base de datos 00:37:54

que ha saludado una persona o en un fichero o que 00:37:58

saque a través de un luminoso, lo que sea. Bueno, todo lo que podamos 00:38:02

programar aquí con Java lo podríamos poner. Para eso tenemos a nuestra disposición 00:38:06

en un método que estamos llamando en algún momento. 00:38:10

Aquí, bueno, para argumentarlo vamos a poner aquí otro mensaje 00:38:14

que sea, soy un alumno. 00:38:17

Entonces, si hacemos esta ejecución, fijaros cómo la ejecución 00:38:24

del saludar del alumno, como está sobrescrito, me llama 00:38:33

al saludar propio del alumno y el saludar propio del alumno 00:38:36

lo primero que hace a través de la etiqueta super que viene 00:38:39

a ser padre, llama al método saludar, me muestra lo que 00:38:43

hace el método saludar del padre y luego continúa ejecutando, dice 00:38:47

soy un alumno, por aquí, se acaba el saludar del alumno 00:38:50

y luego como saluda el profesor, ¿verdad? El profesor 00:38:55

que no tiene sobrescrito el método, pues el único 00:38:59

que utiliza es el que tiene disponible por herencia y me saca 00:39:02

el hola soy una persona. Bueno, pues para ver 00:39:07

la etiqueta super 00:39:10

el método este overwrite 00:39:12

fijaros 00:39:17

la etiqueta 00:39:18

el método no, la etiqueta esta overwrite 00:39:25

que ya os digo que no es imprescindible 00:39:27

imaginaos que yo pongo aquí public 00:39:29

estoy programando la clase alumno y digo 00:39:31

voy a sobreescribir un método 00:39:33

de la 00:39:35

en la clase alumno un método 00:39:35

de los que tenga heredados, en este caso 00:39:39

heredados de la clase persona 00:39:41

entonces si yo pongo aquí 00:39:42

saludor, en lugar de saludar, ¿vale? 00:39:45

¿Veis que se me queja? ¿Por qué? Porque le he dicho que este método 00:39:52

es un método que estoy sobreescribiendo de la clase padre y dice 00:39:56

la clase padre no tiene ningún método que sea saludor. Si quitamos este overwrite 00:39:59

no me compila por más cosas, vamos a poner aquí un public void 00:40:04

Si quitamos aquí este overwrite, fijaros que 00:40:11

ahora sí me compila. ¿Por qué me compila? Pues porque lo considera saludor 00:40:18

como un método de la clase alumno, no un método que está sobrescribiendo 00:40:22

de ningún sitio. Pero si pongo yo aquí el override, ya no me compila. 00:40:26

¿Por qué? Porque dice, está diciendo que lo siguiente que vas a identificar 00:40:31

es un método que vas a sobrescribir de la clase padre y la clase padre 00:40:34

no tiene ningún método saludor. No me gusta lo que estás haciendo. 00:40:38

Entonces, esta etiqueta, sin tener ninguna consecuencia 00:40:42

durante la ejecución en el programa, nos garantiza que si ponemos 00:40:46

el arroba overwrite, lo siguiente que estaremos poniendo es 00:40:51

un método que de verdad tiene heredado desde la clase padre y 00:40:55

nos evita un posible error como el que estoy cometiendo yo aquí 00:40:59

al poner saludor en lugar de saludar. Ya pongo saludar y ya me compila de nuevo. 00:41:03

¿Por qué? Porque saludar sí está disponible en el padre y en verdad lo estoy 00:41:07

sobreescribiendo. En relación a esta etiqueta 00:41:11

que os había puesto aquí, del overwrite. 00:41:16

más cosas que os puedo contar de esto 00:41:18

el super, el override 00:41:28

irme parando, si tenéis dudas o algo me vais diciendo 00:41:30

si alguna cosa no queda clara 00:41:34

las relaciones de composición y la relación de herencia 00:41:37

la herencia solamente puede ser desde una clase 00:41:41

aunque tenemos disponible herencia 00:41:45

desde la clase object 00:41:48

fijaros, aquí estamos utilizando 00:41:52

el método saludar, heredado por la clase, tanto profesor 00:41:55

alumno, desde la clase persona, podríamos poner 00:42:00

mi punto 00:42:04

a ver, mirad, string s 00:42:06

aus, ponemos aquí una variable auxiliar 00:42:11

ponemos aquí mi prof.toString 00:42:14

y ahora vamos a poner aquí un system.out.println 00:42:19

Println de SAUS. 00:42:24

Println, ahí está. 00:42:33

Fijaros, el método toString no está definido ni en el profesor, 00:42:35

ni en la clase que tiene identificada como herencia, 00:42:41

ni en la clase persona. 00:42:46

Pero en cambio, me compila. 00:42:47

¿Por qué me compila? 00:42:48

Pues bueno, porque toString lo tenemos disponible desde la clase 00:42:50

object. 00:42:54

A ver si no lo chiva por aquí. 00:42:54

Fijaros, aquí en esta primera parte nos dice que lo tiene disponible desde java.lang.object.toString, efectivamente, de la clase object. 00:42:55

Y dice, aquí devuelve un string que representa el objeto. 00:43:05

Este string lo hemos cargado en esta variable y lo vamos a mostrar aquí por pantalla. 00:43:12

Mirad, si le damos aquí a ejecutar, mirad lo que nos muestra. 00:43:16

nos muestra 00:43:20

que pertenece a un objeto de la clase profesor 00:43:22

y un código que probablemente tenga que ver 00:43:27

muy probablemente es un código identificativo 00:43:30

de este objeto y probablemente yo siempre digo 00:43:33

aunque no tengo una certeza al 100% que a lo mejor hasta tiene que ver 00:43:35

con la relación en memoria RAM de donde está 00:43:38

almacenada la información del objeto 00:43:41

gracias a que le hemos hecho un new por aquí 00:43:44

¿por qué nos muestra esto? 00:43:46

tan poco identificativo de lo que es un profesor. 00:43:50

Pues fijaos, nos muestra esto porque el método toString 00:43:55

lo está heredando desde la clase Object. 00:43:57

Entonces, y hemos dicho que cualquier clase que tengamos 00:44:01

en nuestro programa tiene disponible este método, 00:44:05

el método toString. 00:44:08

Entonces, pensad que el código que hayan implementado 00:44:10

en las librerías de Java para la clase Object, 00:44:14

en particular para el método toString, 00:44:18

Tiene que valer para cualquier tipo de objeto que se le ocurra hacer a cualquiera en Java. 00:44:20

¿Por qué? Porque cualquier tipo de objeto que se le ocurra a cualquiera en cualquier contexto en Java 00:44:27

tendrá heredado el método toString desde la clase Object. 00:44:32

En verdad, si buscamos algo que nos identifique a una persona con el toString o a un alumno, 00:44:36

a un profesor en este caso, pues estaríamos pensando más en alguna información de sus atributos. 00:44:44

En este caso no tiene ninguno profesor y por herencia tiene estos. Por ejemplo, el nombre. Pues diríamos, oye, que el toString nos devuelva mejor el nombre, ¿no? Y no esto. Porque esto, ¿qué me dice de un profesor en particular? Pues nada. O que me devuelva su edad, o que me devuelva el nombre diciéndome, tiene un nombre tal y su edad es no sé cuál, ¿vale? Pues eso sería algo más razonable para identificar un objeto de una persona que no esté dato. 00:44:49

pero si estamos utilizando 00:45:15

el toString heredado desde Object 00:45:19

no podríamos ir al código 00:45:21

de Object en las librerías 00:45:23

y decir devuélveme un nombre y una edad 00:45:25

porque en otro programa que también 00:45:27

tendrá un string heredado de ese mismo código 00:45:29

Object, pues igual estamos hablando 00:45:31

de algo que no tiene edad 00:45:33

o que no tiene nombre, yo que sé 00:45:35

de colores, es una clase colores 00:45:37

con los diferentes matices 00:45:39

o en esa decimal 00:45:41

justo si tendría 00:45:42

a lo mejor los colores un nombre 00:45:45

pero no tendría una edad 00:45:47

entonces si decidimos en la clase 00:45:48

object para que cuando herede 00:45:50

mi clase persona poner en el código 00:45:52

algo relacionado con la edad 00:45:55

de esa persona, ya no me valdría 00:45:57

ese toString para cuando lo esté 00:45:59

utilizando un objeto de la clase 00:46:01

colores que también hereda de la clase 00:46:02

object, entonces han tenido que buscar 00:46:05

en el toString 00:46:07

definido en la clase object algo que 00:46:08

me valga para cualquier clase en el mundo mundial. 00:46:11

Entonces, todas las clases con toda seguridad tendrán un nombre 00:46:13

y un identificador. 00:46:16

Para particularizar en mi programa este toString, 00:46:19

¿qué es lo que puedo hacer? 00:46:22

¿Qué es lo que he hecho para particularizar el método saludar 00:46:23

en la clase alumno respecto a lo que tenía el método saludar 00:46:26

de la clase persona? 00:46:31

Pues le he hecho una sobrescritura. 00:46:32

Entonces, yo podría coger aquí y decir overwrite. 00:46:34

Esto es opcional solo. 00:46:37

public string 00:46:38

to string 00:46:42

a ver de que se me queda 00:46:44

bueno, me está diciendo que devuelva 00:46:56

y por ejemplo puedo poner aquí un return 00:46:58

hola 00:47:00

que es lo que estoy haciendo 00:47:02

un alumno, perdón lo he puesto 00:47:06

en la clase alumno y en el otro sitio 00:47:09

lo hemos utilizado 00:47:11

con la de profesor, no venimos aquí a la profesor 00:47:13

la misma jugada 00:47:15

Un profesor, sabíamos que tenía este método disponible y antes de sobrescribirlo, lo tenía disponible heredado desde Object. Ahora, ¿qué he hecho con el profesor? Pues lo he sobrescrito y este toString que hace devuelve hola. 00:47:17

ejecuto por aquí, fijaros como ya en lugar de salirme ese código 00:47:33

ya utiliza en primer lugar la forma 00:47:40

en la que hemos puesto el toString para la clase 00:47:44

profesor, a ver vamos a poner aquí, no sé si 00:47:49

super para los, si mirad, si ponemos aquí un super de toString 00:47:52

pues se irá a buscar el del padre que en principio sería el de la clase 00:47:56

object, el toString de esta clase lo que estará 00:48:00

haciendo será devolver un string. Vamos a mostrarlo por pantalla. 00:48:09

En este caso la ejecución ahora la repasamos otra vez si es necesario. 00:48:25

Fijaros que ahora ya lo que hace es mostrarnos lo de la clase 00:48:30

object. Aquí en la clase profesor 00:48:33

el método toString lo que hemos dicho ha sido, oye, devuélveme 00:48:37

lo que devuelve el toString de la clase 00:48:41

Padre, que lo tiene heredado desde la clase Object. 00:48:45

Como devuelve un string, el toString, hemos dicho que lo muestre por pantalla. 00:48:49

Y luego lo que hemos hecho ha sido hacer un return de hola. 00:48:54

Este system out me ha mostrado esto 00:48:58

y este return de hola lo ha cargado 00:49:00

en esta variable souse y este otro system out es el que me lo ha escrito por pantalla. 00:49:04

Es decir, hemos cogido el control de lo que devuelve el 00:49:09

toString y lo hemos particularizado para lo que queremos que pase 00:49:15

cuando se llame al método toString de la clase Persona. ¿Cómo? Sobrescribiendo 00:49:18

el que tiene heredado, que en este caso era una herencia de la clase 00:49:23

Persona en la clase Profesor, sino lo tenía heredado desde la clase 00:49:27

Object. Vale, pues ya, hola, soy un profe. Vamos a poner aquí 00:49:31

soy un profesor. Ejecutamos 00:49:37

y efectivamente ya es algo 00:49:46

que nos dan más pistas de lo que diría 00:49:49

con el toString un profesor que si ponemos esto. Pero si tenemos 00:49:53

15 profesores y en el toString decimos hola soy un profesor 00:49:57

todos ellos me van a decir hola soy un profesor. 00:50:02

Entonces, ¿qué podemos hacer? Pues podemos aprovechar información de cada uno 00:50:06

de los profesores en particular. ¿Y dónde tenemos particularizado cada uno de los profesores? 00:50:10

En sus atributos. Entonces, si para este 00:50:14

profesor antes de llamar a saludar cogemos y le 00:50:18

decimos que su ese nombre si tuviéramos privadas estas estos 00:50:22

atributos lo daríamos con setters y getters pues decimos que es valeria su 00:50:27

nombre y mi prof punto y edad 00:50:33

Decimos que tenga 13 años, pues ahora cuando llamemos al método toString, por aquí, podemos coger y decir que, bueno, un profesor de 13 años hemos dicho, pero bueno, podríamos decir que lo que devuelva, en lugar de ser una cadena así directamente, pues sea un hola, soy. 00:50:39

Y aquí aprovecho y en esta cadena aprovecho y le meto información de sus atributos. Ese nombre y tengo y edad. Antes de hacer el retune del stream, pues aprovechará y hará esta transformación. 00:51:09

entonces si ejecutamos por aquí, fijaros como ahora ya dice 00:51:39

hola soy Valeria y tengo 13 años, ese toString inicial que teníamos 00:51:44

que decía que era de la clase profesor 00:51:48

y un identificador, hemos conseguido particularizarlo 00:51:52

para cada uno de los profesores 00:51:56

mediante la acción de identificar 00:51:59

en la programación orientada a objetos que es la sobrescritura de métodos 00:52:04

y particularizándolo de esta forma. 00:52:07

¿Qué hemos hecho? Hemos llamado un método toString 00:52:15

que devolvía un string, 00:52:17

que es como está identificado en la clase object. 00:52:20

En particular, el método toString ya hemos hablado 00:52:23

y lo que hemos hecho ha sido capturar lo que devuelve ese string 00:52:25

que devuelve el método toString en una variable 00:52:29

y luego mostrar la información de esa variable. 00:52:31

El método toString, en particular, aparte de esta función 00:52:35

que acabamos de ver que tiene es el que se utiliza 00:52:38

directamente Java 00:52:42

considera cuando nosotros ponemos aquí 00:52:45

el nombre de un objeto, miProf 00:52:48

ponemos esto solo, lo que hace es buscar 00:52:49

el método toString para cargarlo en el 00:52:54

System.out.println, entonces si ponemos esto fijaros como al ejecutarlo 00:52:57

me saca esa información 00:53:00

del toString, es decir lo mismo que habíamos hecho aquí en dos pasitos 00:53:03

que era, oye, tu string me devuelve lo que hayamos programado en ese método dentro de la clase profesor. 00:53:06

Lo voy a guardar ya que devuelve un string, que es lo que hemos puesto aquí, que devuelve un string. 00:53:13

Lo voy a guardar en una variable auxiliar string y luego escribo lo de la variable auxiliar. 00:53:19

Pues si directamente ponemos aquí la referencia a la clase profesor, aunque tengas más métodos identificados por aquí, 00:53:25

Java lo que hace siempre cuando integras una referencia dentro de un println es buscar el toString, que es precisamente lo que muestra aquí. Por eso es un método importante y por eso, por ejemplo, es un método disponible en toda clase que tengas, toda, toda lo tiene disponible, la forma de tenerlo disponible toda clase, aunque tú no lo escribas, es mediante enencia de object, porque cualquier referencia la puedes poner en el println. 00:53:32

Y si no estuviera disponible por herencia desde object, los programas no nos compilarían. Más allá de que si no lo sobreescribimos, la información que nos dé no sea muy significativa en este caso de un objeto de la clase profesor. 00:54:00

Pero sí, al tenerlo de herencia, aunque sea una información muy general y no muy útil, permite, nos garantiza que a través de esa herencia cualquier println no va a funcionar porque lo que utiliza aquí es el método toString y lo tiene todo objeto heredado desde la clase object. 00:54:14

¿Sí? ¿Se entiende? ¿Más o menos? ¿No hay dudas de momento? No, vale. Vale, pues nada, esto tenemos con la herencia. 00:54:31

Otra de las características que tenemos en la programación orientada a objetos es el polimorfismo. 00:54:54

Morfismo. ¿Esto qué nos permite? Pues fijaros, si nosotros cogemos y definimos aquí en el main un objeto de la clase persona, en este contexto una persona, según el enunciado de un posible ejercicio que estuviéramos haciendo, pues diríamos, hay un ejercicio, en este ejercicio van a participar alumnos y profesores. 00:55:01

Ambos dos son personas con estas características en común. Estas características en común de alumnos y profesores serían las que podríamos poner en la clase persona, ya que los dos luego van a heredar de la clase persona, pues solo los escribimos ahí en un sitio. 00:55:41

Y luego el enunciado podría continuar diciendo, los alumnos tendrán su número de matrícula como atributo, mientras que los profesores tendrán su número de cuenta para cuando les ingresen la nómina. 00:55:55

Los alumnos, como desafortunadamente no cobran por estudiar, pues no tienen nómina y los profesores no tienen número de matrícula porque no se han matriculado en ningún curso. Entonces, todas aquellas cosas comunes las podríamos poner en la clase persona y las particulares en la alumno y en la de profesor. Por herencia, las comunes las tendrían desde la clase persona por herencia a través del Stents que hemos puesto aquí al definir la clase tanto en una como en otra. 00:56:06

Imaginaos que arrancamos el programa y este programa consiste en que solamente se va a conectar un alumno o un profesor, uno de los dos 00:56:35

Y a través de esa conexión va a saludar 00:56:47

Pero al principio podríamos no saber si va a ser un alumno o un profesor 00:56:56

Imaginaos una clínica veterinaria que cuida a gatos y perros y cada día le pueden venir, a lo mejor atiende hasta dos animales cada día y le puede venir un gato, un perro, dos perros o dos gatos. 00:57:01

Entonces, si yo cojo y defino aquí de forma directa alumnos, o lo que sería en el otro caso gatos, como va a ser uno solo, mi al igual a new alumno, pues ya mal iría, porque si quien saluda hoy es un profesor. 00:57:13

Y si defino un profesor, mal iría si lo que defino aquí es un alumno. Pero en cambio, tanto si es un profesor como un alumno, pues está claro que va a ser una persona. 00:57:32

Entonces, tenemos la posibilidad de definir una persona y que luego esta referencia a persona coja bien la forma de alumno o bien la forma de profesor para seguir ejecutando el programa. 00:57:43

Entonces, ahí viene el tema un poco de lo que definimos como poliformismo. 00:57:57

Bueno, normalmente lo que haríamos es que si, imaginaros que vamos a tomar aquí el criterio de selección que lo metemos por teclado, pero a lo mejor sería que leemos un fichero, bueno, el criterio de selección podría ser uno u otro. 00:58:02

Aquí vamos a decir si lo que entra es un alumno al final en la ejecución de este programa o es un profesor. En tiempo de ejecución, no en tiempo de desarrollo del programa ni en tiempo de compilación, sino ya en tiempo de ejecución vamos a meter por teclado, cuando estemos ejecutando el programa, si quien entra hoy es un alumno o un profesor. 00:58:27

Y así esta persona cogerá la forma de alumno o cogerá la forma de profesor. Esto que vamos a identificar es la forma que vamos a utilizar a través de teclado para identificar que es una persona, pues bueno, podría ser a través de, bueno, yo qué sé, de un lector de cámaras que de repente identifica si es un chico o una chica según tiene barba o no tiene barba o yo qué sé qué deciros o si lo lee de una base de datos y resulta que en la base de datos para el día de hoy justo la entrada dice que era un chico o que era una chica. 00:58:46

Como aquí no tenemos para leer de base de datos de momento ni la cámara para hacer una identificación, pues lo vamos a capturar desde teclado. 00:59:22

Entonces aquí cogemos y decimos un System.out. 00:59:30

Decimos para arrancar el programa, oye, mira, lo que quiero es que sea una persona. 00:59:40

Aquí pongo miper.saluda. 00:59:46

Fijaros que quien saluda es el objeto de la persona. 01:00:03

indica chico o chica 01:00:06

chico o chica no, es alumno 01:00:29

alumno o profesor 01:00:33

mi scan.nextline 01:00:36

y ahora aquí cogemos y hacemos un casting 01:00:47

al tipo de objeto que sea, entonces decimos 01:01:05

ese, si ese aus punto 01:01:07

compare to, si es 01:01:11

no vamos a validar mucho, vamos a decir chico en minúsculas 01:01:15

chico no, alumno o profesor 01:01:20

entonces aquí cogemos y decimos mi per 01:01:29

que sea, a ver 01:01:34

aquí no lo hacemos el new, vale, y aquí cogemos 01:01:41

y aquí decimos miper que sea igual a new 01:01:46

alumno 01:01:48

en lugar de compare tú vamos a poner equals 01:01:49

método equals 01:01:56

si no es un alumno, es un profesor 01:01:58

entonces lo que hacemos 01:02:08

es definir 01:02:09

me falta el new 01:02:14

lo que hacemos es definir 01:02:17

una referencia, una persona 01:02:20

no lo hacemos el new, había puesto el new persona antes 01:02:21

no se lo hacemos, y terminamos haciéndole un new 01:02:24

para decir, oye, esta persona, según el contexto 01:02:27

del programa, según haya ido, aquí lo estamos cogiendo por teclado 01:02:30

pero podría ser mediante algún otro mecanismo, ¿verdad? 01:02:33

Termina siendo un alumno esa persona 01:02:36

coge la forma, poliformismo, es la característica 01:02:39

de la programación orientada a objetos de la que estamos hablando 01:02:42

de un alumno o coge la forma de un profesor 01:02:45

¿Y quién saluda? Saluda mi per 01:02:48

Fijaros que este código es genérico 01:02:51

y en una ejecución resultará ser un alumno y en otra será un profesor. 01:02:53

Y aquí cuando lo hemos definido a la referencia también lo hemos hecho genérico. 01:03:02

Es decir, todo el código es genérico menos en el momento en el que tomamos la decisión 01:03:05

de si esa persona va a actuar como alumno o como profesor. 01:03:10

Va a coger una forma u otra. 01:03:12

Entonces le damos aquí, a ver, salvo por aquí, le doy aquí a ejecutar 01:03:16

Y digo que sea un alumno, y si digo que sea un alumno, pues entonces fijaros cómo ha llamado, a pesar de que hemos utilizado el objeto de la clase, perdonad un segundo. 01:03:22

Natalia, tenemos... Ah, vale, bueno. 01:03:38

No, no, en absoluto, en absoluto. 01:03:51

No, no, no me molestas, no, no te preocupes. 01:03:54

Continúo. 01:03:58

Pues nada, fijaros cómo aquí, en realidad, este saludar, si nos fijamos en este miper y vemos que hemos definido una referencia a la clase persona, lo previsible sería que el saludo dijese hola, soy una persona, ¿verdad? 01:03:59

Bueno, a ver aquí en el principal. Bueno, me ha mostrado los dos, en realidad. Hola, soy una persona y soy... No, a ver, perdón. Lo que ha hecho ha sido el alumno, porque tenemos aquí llamando al super. 01:04:19

Quito el super este, saludar, vuelvo a ejecutar, pues si es un alumno, lo previsible, en principio, si no estuviéramos considerando la característica de sobrecarga de la programación orientada a objetos, 01:04:30

al haber definido mi per como una referencia a persona, sería que este saludar, pues si no viéramos esta parte del código, tendríamos la tentación de coger y venirnos a la clase persona y decir, 01:04:47

Al saludar me va a decir, hola, soy una persona, pero nos ha dicho, hola, soy un alumno. 01:04:58

¿Por qué? Bueno, pues porque hemos decidido hacer el new de un alumno. 01:05:02

Entonces, el método que en realidad ha utilizado ha sido el método saludar de la clase alumno. 01:05:12

Si os fijáis, aquí le estamos haciendo como alternativa el new sobre la clase profesor. 01:05:20

Entonces, si hacemos una nueva ejecución, aquí ahora decimos que lo que queremos es que sea un profesor, nos dice hola, soy una persona. En realidad nos está saludando como saludan los profesores. Si nos vamos a la clase profesor, el método saludar no existe. Como no existe, ¿cuál utiliza? El que tiene heredado de la clase persona, entonces nos ha dicho hola, soy una persona, pero ha saludado como si fuese un profesor. 01:05:26

si en la clase profesor sobrescribimos el método 01:05:51

saludar de la clase persona para garantizar que 01:05:56

efectivamente está saludando como un profesor y no como una persona ya que nos ha sacado este texto 01:06:00

nos venimos por aquí, podemos poner la etiqueta 01:06:04

overwrite esta para garantizar efectivamente que no 01:06:09

nos hemos equivocado y si que estamos sobrescribiendo algo 01:06:13

y ahora en la clase profesor respecto al comportamiento que teníamos de la clase 01:06:16

persona, lo modificamos y decimos, hola, soy un profesor. 01:06:21

Entonces, hacemos una nueva ejecución y vamos a hacer el new. 01:06:27

Vamos a darle forma de profesor a algo que inicialmente 01:06:31

era una referencia a una persona. Le digo 01:06:35

profesor por aquí. Y fijaros cómo efectivamente ya su comportamiento 01:06:38

no es como el de una persona, sino el método 01:06:43

saludar actúa como lo tenemos sobrescrito. Dice, hola, soy un profesor. 01:06:48

Bueno, pues esto es otra de las características de la programación orientada a objetos que nos hace referencia a este tema y que tiene que ver con el polimorfismo, es decir, un objeto definido en el programa de una determinada forma puede coger las diferentes formas de objetos de aquellas clases que son hijas suyas. 01:06:53

Es decir, que la tiene identificada con Stents como hijas gracias a la etiqueta Stents, ¿verdad? De la clase padre. 01:07:18

Claro, sí. La idea de esto es, aquí yo tengo capacidad de que un objeto coja diferentes formas. Fijaros cómo estamos haciendo que coja la forma de alumno a través de la característica de polimorfismo de la programación orientada a objetos. 01:07:27

Que coja la forma de alumno o que coja la forma de profesor. Este if que he puesto aquí lo hemos capturado desde teclado mediante un objeto de la clase escáner, pero podría haber sido por diferentes medios. Imaginaros que los días lunes, miércoles y viernes saludan los profesores y los martes y los jueves saludan los alumnos. 01:07:56

pues aquí podríamos coger del sistema el día que es 01:08:17

y según una cosa, por decir, oye, pues si el lunes, miércoles o viernes, 01:08:21

que sea un alumno, y si el jueves o martes, que sea un profesor. 01:08:24

Aquí es donde tomamos la decisión de que un objeto tome una forma en particular. 01:08:29

Pero aquí el código es general y aquí el código es general. 01:08:34

Aquí yo no he puesto código particular para que sea un alumno 01:08:38

ni para que sea un profesor, ni aquí tampoco, en todo esto. 01:08:42

Entonces, ¿en qué momento se aplica el polimorfismo a un objeto que de inicio era un objeto de la clase persona? 01:08:46

Pues se aplica cuando hacemos el new al identificar que tome forma de alumno o que tome forma de profesor. 01:08:53

¿Sí? 01:09:04

Eso es, claro, claro. 01:09:10

Claro, ¿por qué? 01:09:13

Ahora intentamos a ver si nos deja Eclipse que compile si no es hija. 01:09:16

Vamos a intentarlo, yo creo que no nos va a dejar, pero bueno, vamos a buscar un poco un razonamiento antes de coger e ir con el código a ver si nos compila o no. 01:09:20

Fijaros que aquí lo que estamos llamando es a un método saludar que está disponible en la clase persona. 01:09:29

Si yo utilizo aquí un saludar y aquí le hago un new de algo que no sea su hijo, esa otra clase que no es su hija podría no tener el método saludar. 01:09:38

En cambio, todo aquel que sea su hijo, con toda seguridad, tiene el método de saludar porque o bien lo tiene sobrescrito o como poco lo tiene heredado de la clase padre. 01:09:49

Imaginaos aquí la clase humano. Tiene la clase saludar, el método de saludar. Se lo voy a borrar para que no exista. 01:09:59

saludar 01:10:06

si yo cojo y aquí cojo 01:10:08

y quiero que 01:10:10

esta referencia a la clase persona 01:10:12

en realidad se comporte como un humano 01:10:14

cuando llegase aquí y dijese 01:10:16

igual que aquí se estaba comportando 01:10:18

como un alumno, como un profesor 01:10:20

si al llegar aquí fuese un humano 01:10:21

cuando llamo al método saludar, el programa me diría 01:10:23

saludar, que saludar 01:10:26

si tú no tienes definido aquí saludar 01:10:28

ni lo tienes disponible por herencia 01:10:30

de ningún sitio, pues eso no me vale 01:10:32

¿lo veis? 01:10:34

vamos a intentar aquí a ver si nos deja hacer un new 01:10:38

pero yo entiendo que no 01:10:45

porque no, vamos, fijaros que directamente 01:10:47

ya no me deja el IDE, a ver que nos dice 01:10:51

dice no puedes convertir un humano a una persona 01:10:53

no puedes coger esa forma 01:10:56

no puedes utilizar la característica de poliformismo 01:10:59

por eso simplemente, directamente no nos deja 01:11:01

y si queremos buscar una explicación lógica, pues podría ser esta que te cuento 01:11:04

Un humano no podría saludar porque no tiene código para saludar, ni implementado ni heredado. En cambio, todo aquel que sí que herede de persona, obvio, lo tiene sobrescrito y ejecutará este código, pero si no lo tiene, lo tendrá disponible por herencia desde la clase principal, que es la clase para la cual hemos definido aquí la referencia al objeto, miper en este caso. 01:11:09

claro, es que este es el momento 01:11:36

en el que aplicamos polimorfismo 01:11:52

que haces el new para que se comporte como un alumno 01:11:53

o haces el new para que se comporte como un profesor 01:11:57

si no haces este new 01:11:59

¿qué es lo que tienes? 01:12:01

pues lo que tienes es 01:12:04

un programa normal sin polimorfismo 01:12:05

pues tendrías una persona que saluda 01:12:08

y como quien saludaría 01:12:11

pues bueno, aquí no me compila 01:12:12

porque no le he hecho aquí el new para que sea una persona, ¿verdad? 01:12:14

Pero como me saludaría como una persona y ya está. 01:12:17

Sería una persona sin polimorfismo ni nada. 01:12:20

Entonces la característica de polimorfismo es 01:12:22

no la proporciona en este momento hacer un new o hacer otro. 01:12:24

¿Sí? ¿Se entiende? Vale. 01:12:34

Bueno, pues aprovechéis los foros y volvéis a preguntar. 01:12:40

Acordaros que os respondo gustosamente, 01:12:43

pero aunque fuera un poco menos gustosamente me pagan por esto, 01:12:45

así que no me queda más remedio. 01:12:48

así que los aprovecháis y me preguntáis por ahí. 01:12:49

Bueno, mirad, introducido un poco el polimorfismo, hemos hablado en esta tutoría 01:12:53

de varias características de la programación orientada a objetos, polimorfismo ahora, 01:12:59

hemos hablado de la ocultación o, como lo decíamos, cuando teníamos el código oculto 01:13:03

y simplemente veíamos una clase daba la cara a una clase y, por tanto, los objetos, 01:13:11

cuando llamábamos a métodos y atributos, daba la clase a través de su protocolo, su interfaz. 01:13:16

También hemos hablado de la sobrecarga, que hemos sobrecargado el método saludar. 01:13:22

Cuando no estamos hablando de Java y estamos hablando de programación orientada a objetos 01:13:28

y te explican lo que son las clases, lo que son los objetos, lo que son las características, 01:13:32

pues hay cinco o seis conceptos que son los que de base definen la programación orientada a objetos. 01:13:36

Y estos tres, la extracción era este que te oculta la información para que no la veas y simplemente interactúes con los objetos a través de sus interfaces. Pues estos conceptos de programación orientada a objetos, los diferentes lenguajes, si quieren ser realmente lenguajes basados en este concepto, pues tienen que implementarlos. 01:13:41

y ahora estamos viendo, por ejemplo, cómo Java implementa algunos de ellos. 01:14:04

Y otra cosa que también habíamos hablado algún día 01:14:12

son las clases abstractas y de la mano de las clases abstractas 01:14:15

los interfaces, que vendrían a ser como unas especies de clases abstractas 01:14:20

un poquito más llevadas al último extremo. 01:14:25

Vamos a repasar un poco estos conceptos, que también os habla de ellos en este tema. 01:14:27

Tú dentro de una clase es posible que definas aquí 01:14:33

mediante algún método, mediante la etiqueta abstract, public, abstract, despedir y pones aquí un punto y coma. 01:14:37

A ver, tenemos que decir si devuelve algo, abstract, voy, despedir no devuelve nada, a ver, ¿por qué todavía no me compila? 01:14:50

Voy a ponerlo con minúscula, aunque ese no es el motivo por el que no compile. 01:15:01

vale, bueno, puedo definir un método abstracto 01:15:04

y aquí ahora mismo no me está compilando porque me dice, oye, si tú tienes en una clase 01:15:13

un método que sea abstracto, fijaros que no me compila tampoco, la clase también 01:15:17

tiene que ser abstracta, vale, ya me compila, fijaros que cuando he definido 01:15:21

el método despedir, como, y le he puesto la etiqueta 01:15:27

abstracta, el resto de etiquetas ya las conocemos, el public y el void 01:15:31

me ha obligado también a poner que la clase sea abstracta 01:15:35

He puesto, después de la asignatura o encabezado de este método, he puesto un punto y coma y no, como solemos hacer al uso, la apertura y cierre de llaves con el código que realmente se ejecuta cuando llamamos a ese método. 01:15:39

Es decir, aquí no he dicho lo que tiene que pasar cuando un profesor se despide. 01:15:52

¿Y para qué hago esto? Pues parece un poco inútil si no lo explicamos un poquito más, cosa que vamos a hacer ahora. 01:15:56

aquí lo que estoy diciendo es cuando haya algo que sea un profesor 01:16:05

pues quiero que mediante el método este sobre escrito 01:16:10

el toString se comporte de esta forma, tenga unos determinados 01:16:13

esperad porque esto, más que aquí lo quería meter en otra clase 01:16:17

voy a quitarlo de aquí y me lo voy a llevar a la clase, no profesor sino a la clase 01:16:22

persona, también podría estar en la otra pero para contarlo 01:16:26

me facilita la cosa tenerlo aquí, entonces cuando 01:16:36

algo sea una persona, yo podré saludar 01:16:40

mediante esto, tendrá estas características, pero el hecho de definir 01:16:44

la clase abstracta, lo que me permite es 01:16:48

definir métodos que sean abstractos, y estos métodos abstractos lo que hago es 01:16:51

no identificar el código que va a tener en respuesta a la llamada a este método. 01:16:55

¿Para qué sirve esto? Pues esto me sirve para que 01:17:01

las clases que sean hijas de la clase 01:17:03

persona, en este caso la clase alumno y la clase profesor, estoy de alguna 01:17:08

forma obligando a que estas clases, toda clase que quiera ser hija de la clase 01:17:12

persona, heredará sus atributos y sus métodos 01:17:16

pero además tienen que firmar conmigo un contrato, como si sacáramos 01:17:20

ahí un papel y delante del notario echáramos una firma, oye tú si quieres ser alumno 01:17:24

hijo mediante STEM de la clase persona, obligatoriamente 01:17:28

tendrás que ser capaz de despedirte, yo no te voy a decir cómo, pero sí 01:17:32

que quiero que te puedas despedir y si no, olvídate de ser 01:17:36

una clase hija mía, ¿vale? ¿Cómo te tienes que despedir? Yo no te lo estoy 01:17:40

diciendo. ¿Cómo tienes que saludar? Si no lo escribes, saluda así. 01:17:44

Esto sí, pero el despedirte no te lo voy a decir, 01:17:48

pero sí que quiero que tengas esa posibilidad de despedirte. Fijaros cómo desde el 01:17:52

momento en el que hemos metido el método despedir como clase abstracta, 01:17:56

la clase alumno ha dejado de compilarme y la clase profesor también ha dejado de 01:18:00

compilar. ¿Por qué? Porque ahora son hijas de una clase abstracta con algún 01:18:04

método sin implementar. Y es eso en lo que consiste 01:18:08

la clase abstracta. Es un acuerdo de, no te voy a decir 01:18:13

cómo, pero despídete. ¿Por qué? Pues porque 01:18:17

toda persona en el programa en general, cuando instancie un objeto de la clase 01:18:20

alumno, tendrá que tener a través del interfaz de la clase alumno la posibilidad 01:18:25

de despedirse. Si yo no te pongo aquí esto como abstracto, 01:18:29

como no lo tienes heredado, si tú no lo implementas aquí en tu código, 01:18:33

luego igual alguien que instancie un alumno y quiera llamar al método de despedir 01:18:37

no va a ser capaz. ¿Por qué? Porque ni existe en la clase alumno ni lo tiene disponible 01:18:41

por herencia. Pero si lo pongo así, pues ya te obligo. 01:18:45

Entonces, si vengo aquí a la clase alumno ahora, nos ayudamos 01:18:50

del IDE, que siempre nos ha hecho una mano estupenda para estas cosas, 01:18:53

pues fijaros cómo al ponerme sobre el error me dice que 01:18:58

añada los métodos que están sin implementar. 01:19:01

Entonces, le doy aquí ahora, ¿y qué método me añade? 01:19:05

El despedir. ¿Por qué? 01:19:07

Porque a través de la herencia he firmado como alumno, 01:19:08

al ser su hija, un acuerdo para implementar aquellos métodos 01:19:12

que la clase persona tiene definidos como abstractos. 01:19:16

Entonces, voy a ir aquí a salvar. 01:19:20

Fijaros cómo la clase alumno ya me empieza a compilar. 01:19:21

Ahora tendré que meter aquí el código de cómo se despiden los alumnos, ¿verdad? 01:19:25

por herencia no tengo ningún método 01:19:28

ningún código disponible desde la clase padre sobre cómo despedirme 01:19:32

pero al ser abstracto me ha obligado a implementar un código 01:19:36

de cómo se despiden los alumnos, con lo cual cuando para un alumno 01:19:40

llamemos al método de despedir pues ya hará el código 01:19:44

que tengamos puesto aquí, system.out, vamos a poner aquí un system.out 01:19:49

y decimos, bueno pues 01:19:52

algo sencillo, soy un alumno y me despido 01:19:58

¿Qué nos sucede en la clase 01:20:01

profesor que todavía no nos compila? Pues lo mismo 01:20:09

que nos estaba pasando en la clase alumno 01:20:10

hereda de persona y 01:20:12

aquí, en el momento que ha dicho 01:20:15

que heredo, ha firmado un acuerdo 01:20:17

con la clase persona 01:20:19

de que todos aquellos métodos 01:20:20

que tenga como abstractos, los tendrá que 01:20:23

implementar, porque en el contexto 01:20:24

de este programa, todo aquel que sea una persona o un hijo 01:20:26

de una persona tendrá que tener la posibilidad de despedirse porque desde clases terceras 01:20:30

por ahí a lo mejor vamos a querer que los profesores, en un momento haremos una llamada al método 01:20:34

de despedir. Pues nada, si me pongo aquí sobre el profesor, fijaros que lo que 01:20:38

me requiere aquí el IDE es de nuevo que meta los 01:20:42

métodos que no están implementados, pues ya está, me pone el despedir, fijaros 01:20:46

como me pone la etiqueta override, ¿por qué? porque estamos sobrescribiendo 01:20:50

el despedir de la clase Persona, que en verdad no tenía código, pero lo estamos sobrescribiendo. 01:20:55

Voy a hacer copy de esto por escribir menos. 01:21:02

Y aquí decimos soy un profesor. 01:21:06

Y ya está, pues ya tenemos otra vez el programa en marcha. Fijaros como 01:21:12

esto ya está en marcha, ya va bien. Hemos introducido 01:21:15

otro nuevo concepto que es la etiqueta ASTRAD para los métodos 01:21:22

que viene a identificarnos. Métodos sin 01:21:26

métodos donde no indicamos 01:21:28

cómo, qué código Java tiene que ejecutarse 01:21:32

cuando lo hacemos, pero sí que nos obliga a que los hijos de esta clase 01:21:36

tengan que implementarlos. 01:21:40

Aparte del astrat este, fijaros en el método, me ha obligado a poner que la clase 01:21:44

es astrat. ¿Y qué significa que la clase sea astrat? 01:21:48

Pues lo que me va a suponer ahora es que ya no voy a poder instanciar 01:21:52

objetos de la clase persona desde el momento en el que 01:21:56

se abstracta. ¿Y por qué sucede 01:21:59

esto? Pues nada, intentamos buscar la explicación yendo al sentido 01:22:02

común de nuevo. Si yo defino una persona 01:22:05

cuya referencia sea miPer y ahora cojo y pongo 01:22:07

miPer.despedir, vas a ver 01:22:11

ese objeto de la clase persona que hacer 01:22:14

si el método es abstracto y no tiene el código Java de cómo 01:22:16

se tiene que comportar, pues no. Entonces, como no existe 01:22:20

esta posibilidad, en el momento que la clase 01:22:23

es abstracta, ya no podemos instanciar objetos de esa clase y el motivo 01:22:26

es este. Una persona debería ser capaz 01:22:30

de despedirse y no tengo código de cómo hacerlo. 01:22:34

Si vengo aquí ahora y yo cojo y digo 01:22:38

aquí en mi per igual a new persona 01:22:42

y le pongo el constructor, fijaros que directamente no me deja. Y si me pongo por aquí 01:22:44

dice no puedes instanciar un objeto de la clase 01:22:49

persona. ¿Cuál es el motivo? Que la clase persona es abstracta. 01:22:53

¿Y por qué es abstracta? Porque se entiende que hay métodos 01:22:57

que no tienen definido cómo comportarse. 01:23:00

Bueno, aquí me faltaba un new. Igual, bueno, en cualquier caso 01:23:08

sigue sin dejarme con el mismo motivo. ¿Dudas de la clase abstracta? 01:23:12

¿Método y clase abstracta? ¿Para qué nos sirve esta etiqueta? 01:23:19

De alguna forma fijamos comportamientos 01:23:26

en la clase abstracta a través de los métodos 01:23:28

acciones que todo objeto de otras clases hijas 01:23:33

sí o sí dentro de este programa tienen que desarrollar, 01:23:38

tienen que implementar, porque si no, te bloqueo que seas hija 01:23:42

de la clase persona en este caso. Eso para la etiqueta 01:23:45

abstracta en el método. Y para la etiqueta abstracta en la clase, lo que estamos diciendo 01:23:49

es, como tienen métodos no implementados, no vas a poder instanciar 01:23:53

un objeto de esta clase, como hemos visto antes en la clase principal. 01:23:57

¿Bien? ¿Sí? Bueno, fijaros, las clases abstractas 01:24:05

tienen características, tienen métodos desarrollados 01:24:12

y métodos abstractos. Cajón desastre, nos permite tener 01:24:16

de todo. Alguien que sea hijo de una clase 01:24:19

abstracta, la clase alumno, por ejemplo, tendrá esos atributos 01:24:23

disponibles, podrá utilizar por herencia directamente 01:24:28

los métodos que no sean abstractos y que estén desarrollados y estarán obligados 01:24:31

a implementar aquellos que en la clase de padres hayamos 01:24:35

utilizado la clase abstracta. Si queremos dar 01:24:40

un pasito más y considerar 01:24:43

una clase en las cuales, bueno, vamos a decir una clase de momento 01:24:47

en las cuales todos sus métodos nos obliguen a las clases hijas 01:24:51

a desarrollarlos, es decir, que todos sus métodos sean abstractos 01:24:55

y en principio no dispongan de atributos, lo que desarrollamos 01:24:59

es una interfaz. Una clase abstracta puede tener 01:25:04

métodos desarrollados y métodos abstractos. Una interfaz solamente 01:25:08

tendrá métodos abstractos. Vamos a crear una interfaz aquí 01:25:12

en el proyecto. Mirad, nos venimos por aquí, 01:25:16

venimos a New y típicamente nos venimos siempre aquí a clase, pero 01:25:20

fijaros cómo nos da la opción también de, bueno, nos da muchas opciones por aquí 01:25:24

y una de ellas es la de interfaz, le damos aquí al interfaz 01:25:28

vamos a darle un nombre, vamos a poner 01:25:31

yo que sé, que deciros, trabajador 01:25:35

bueno, aquí me define un interfaz 01:25:40

y vamos a, esto es un interfaz, vamos a hacer intentos de hacer cosas 01:25:45

que no nos deje, por ejemplo, vamos a definir un public 01:25:50

void fichar, pues el trabajador tiene que fichar 01:25:54

y para fichar, cogemos y decimos 01:25:59

system.out.println, lo que sea, ¿vale? 01:26:02

system.out.println, fichando 01:26:05

y que dice, se me queja, y hay que ver que nos dice 01:26:12

mirad, a la que voy, la que me interesa 01:26:16

es este removeMethodBody, dice, quita el método 01:26:20

ya lo pongo aquí, y ya me deja 01:26:23

fichar y 01:26:29

cobrar también, mal vamos si no cobramos, si fichamos y trabajamos 01:26:33

y no cobramos, pues esto otro método, fijaros que en el interfaz 01:26:37

en el momento que en uno de los métodos he intentado meter código, no me ha dejado 01:26:41

en cambio lo que me permite es definir 01:26:45

diferentes métodos que todos ellos 01:26:49

serían métodos en verdad abstractos, como se meten 01:26:54

de hecho 01:26:58

bueno, vamos a ponerle 01:27:00

abstract incluso 01:27:03

le apetece que no lo ponga 01:27:04

no lo permite sin ponerlo, pero bueno 01:27:07

vamos a ponérselo incluso 01:27:09

¿Cómo hemos 01:27:10

definido que una clase sea 01:27:13

hija de una clase padre? 01:27:15

Pues hemos utilizado el stents 01:27:17

para los interfaces tenemos otra etiqueta 01:27:18

en la clase 01:27:21

vamos a decir hija de momento, aunque 01:27:22

el tema hijo y padre está relacionado con la herencia 01:27:25

y no con los interfaces, que es la etiqueta implement. 01:27:27

Y aquí es donde ponemos el nombre del interfaz. 01:27:31

Hemos dicho que el interfaz se llamaba trabajador. 01:27:33

Entonces decimos, implementa el interfaz trabajador. 01:27:37

Y en el momento, aparte de la herencia que hemos dicho 01:27:41

que implementa un interfaz, lo que nos obliga es que metamos 01:27:44

los métodos que no están implementados. 01:27:49

fijaros como me obliga a meter el método fichar 01:27:51

y el método cobrar. ¿Qué es lo que hemos conseguido con un interfaz? 01:27:55

Pues hemos firmado un acuerdo, como habíamos hecho antes 01:27:59

en la parte de la herencia para los métodos que eran abstractos 01:28:03

de la clase persona, al ponerlo abstracto este método y no poner su código 01:28:07

firmamos un acuerdo ahí para que las clases 01:28:12

hijas obligatoriamente tuvieran que implementar esos métodos, el despedir 01:28:16

A través de la herencia. Si lo que definimos es una interfaz, los interfaces se parecen a las clases abstractas un poquito en tanto en cuanto define un conjunto de métodos que son todos abstractos, no nos deja implementar ninguno. 01:28:19

Es decir, es un acuerdo puro y duro en el cual se definen una serie de métodos abstractos, no desarrollamos ninguno, en ninguno decimos cómo se tiene que comportar alguien que pretenda ser un trabajador, pero sí decimos que todo aquel que implemente el interfaz trabajador tendrá dentro de su código que meter este método y desarrollarlo, de la misma forma que tiene que hacer con el método cobrar. 01:28:34

Entonces ahora el alumno hereda de la clase persona lo que herede, 01:29:02

si tiene la clase persona algún método abstracto lo tiene que desarrollar 01:29:06

y dice que implementa la clase trabajador, el interfaz trabajador, 01:29:10

con lo cual tiene obligatoriamente que desarrollar todo esto. 01:29:16

Imaginamos que tenemos un proyecto grandote y se pretende que todo aquel 01:29:20

que sea considerado en un momento dado un trabajador, es decir, 01:29:25

implemente esta interfaz, desde diferentes sitios del código 01:29:29

se le podrá llamar a un método fichar y un método cobrar. 01:29:33

Un alumno, que en un momento dado puede ser un trabajador, si no le pongo esto 01:29:37

y le implemente este, no estoy firmando un acuerdo con nadie, pues podría coger 01:29:40

y no implementar el método cobrar. Y si luego desde clases por ahí terceras 01:29:45

alguien dice, como es un alumno y el 01:29:49

diseño general, un requisito general del proyecto es que 01:29:52

sea capaz de cobrar, pues dice, pues vale, pues si me han dicho que los alumnos 01:29:57

en el diseño general del proyecto pueden cobrar, voy a llamar al método cobrar. 01:30:01

Y resulta que si no le he obligado a través de una firma que he hecho ahí 01:30:05

con una interfaz a que lo implemente, he podido, yo que soy 01:30:09

el programador de esta clase en particular, no desarrollarlo. Entonces coge y no me compila 01:30:13

el programa por otros lados. En cambio, si he llegado al acuerdo de que los 01:30:17

alumnos puedan llegar a ser trabajadores, 01:30:21

pues lo que hago es implementar el interfaz 01:30:24

trabajador que no dice cómo hacer nada 01:30:27

pero me obliga a que los alumnos tengan aquí 01:30:30

un código para que pueda ser llamado 01:30:33

a través del método cobrar o a través del método fichar. Entonces aquí 01:30:36

pondremos qué es lo que tiene que pasar cuando un alumno 01:30:39

pues tiene que cobrar, pues yo que sé, que le tienen que dar una pasta 01:30:42

como debería ser. Entonces estos 01:30:44

son los interfaces. Mirad, sobre los 01:30:48

interfaces, otra cosa más. Vamos a definir un segundo 01:30:51

interfaz, aquí 01:30:54

yo que sé, vamos a llamarlo vacaciones 01:30:56

pues oye, vacaciones está bien 01:31:03

y definimos 01:31:06

un método public abstract 01:31:09

void 01:31:11

que sea 01:31:13

viajar 01:31:14

si intentara meter código aquí 01:31:16

por ser una interfaz, no me dejaría 01:31:19

simplemente digo que 01:31:21

todo aquel que 01:31:23

quiera implementar el interfaz 01:31:24

vacaciones que se esté obligando en su cabecera a través del interfaz vacaciones tendrá que hacer 01:31:27

un desarrollo del método viajar y luego pues vamos a poner otro método publicastrat void disfrutar 01:31:33

vale pues también si oye si coge vacaciones olvídate de irte a aburrirte tienes que irte a 01:31:41

disfrutar decimos cómo es el código cualquiera de estos dos métodos 2 3 4 5 20 o 1 no porque 01:31:46

Porque es una interfaz. Y además, fijaros que aquí, aunque sea un poco pesado, cuando estamos de vacaciones también tenemos que fichar. 01:31:54

No sé buscar un contexto real en el que tengamos que fichar, pero también vamos a poner fichar aquí en vacaciones. 01:32:06

Alguien que implemente el interfaz vacaciones tiene que viajar, disfrutar y fichar. 01:32:13

Y alguien que implemente el interfaz trabajador tiene que fichar y cobrar. 01:32:18

bueno, venimos aquí a la clase alumno 01:32:22

que hereda de la clase persona y ya está implementando 01:32:26

trabajador y ponemos aquí una coma y decimos 01:32:29

que también implementa el interfaz vacaciones 01:32:32

ha dejado de compilarme, ¿por qué? pues porque 01:32:35

vacaciones tiene aquí, firma un contrato con el 01:32:38

interfaz vacaciones que tenemos que tener 01:32:41

código desarrollado para estos tres métodos y resulta 01:32:44

oye, pues que no, que es que ahora mismo no tengo 01:32:47

tengo fichar, cobrar, que son los de trabajar. Fichar coincide 01:32:50

con el trabajar, pero vacaciones tiene aquí definidos 01:32:53

dos que todavía no están implementados. 01:32:56

Entonces, vengo aquí y me dice 01:32:59

que añada los métodos 01:33:02

no implementados. Aparecen aquí 01:33:05

disfrutar, viajar, con el override, porque estoy 01:33:08

sobrescribiendo desde la interfaz y ya me compila. 01:33:11

¿Y a dónde he querido llegar al meter dos interfaces? 01:33:16

Pues, ¿qué os decía antes de la herencia? 01:33:19

Una clase en Java, hay algún lenguaje que lo gestiona como sea, hace yo creo recordar, Java solamente permite herencia desde una clase padre. ¿Por qué? Pues porque en las clases padres podemos tener métodos con el mismo código. 01:33:22

Entonces se produce una situación de que si llamamos a ese método no va a saber de qué clase padre si hereda E2 coger el método, el comportamiento que tiene que tener a la hora de ejecutarse para desarrollar ese método. 01:33:37

En cambio, la implementación, si os fijáis, más allá de la herencia esta que os decía de algunos métodos comunes para todas las clases, desde la clase Object que está en la parte de arriba del árbol de todas las clases en Java. 01:33:53

Pero, en cambio, la implementación sí me permite implementar dos interfaces diferentes y podríamos decir, pero claro, si tienes el mismo método definido en dos interfaces, ¿cuál de los dos interfaces considera? 01:34:06

Pero, claro, los interfaces, que es el caso, el interfaz trabajador tiene fichar y el interfaz vacaciones tiene fichar. Es decir, se da esa situación que nos impedía la herencia múltiple en Java. 01:34:22

Pero como fichar no lo tenemos desarrollado de cómo se tiene que comportar, no tenemos ningún problema. Hemos firmado por dos lados que la clase alumno va a tener que implementar, va a tener que desarrollar el método fichar, lo hemos firmado por dos lados. 01:34:39

pero como no tenemos compromiso 01:34:55

de comportarnos de ninguna de las formas 01:34:57

desde ninguno de los dos interfaces 01:34:59

el único método 01:35:00

fichar que de verdad desarrollamos 01:35:03

es decir, el comportamiento no tiene 01:35:05

ambigüedades, es este, por mucho 01:35:07

que este fichar se nos esté 01:35:08

obligando a tenerlo desarrollado 01:35:11

desde dos interfaces distintos, en cambio 01:35:12

cobrar solamente desde uno, pero no me importa 01:35:15

el código es único, no hay ambigüedades 01:35:17

oye, pues te dejo 01:35:19

que implementes más de una interfaz 01:35:20

¿Sí? ¿Se entiende? 01:35:23

¿Alguna cosilla por ahí? 01:35:31

¿No? 01:35:39

Pues, bueno, el tema, como comentabais, el tema 7 es bien largo, 01:35:42

pero las ideas así principales que os quería contar eran un poco estas. 01:35:48

La sobrecarga, la encasulación, la sobrescritura, las clases abstractas, 01:35:52

los interfaces, que no es cosa de poco. 01:35:58

Luego, hasta que consiguierais digerir un poquillo todo esto que os he contado hoy, 01:36:01

Vais a tener que echar algún ratín. Si no tenéis alguna duda por ahí en particular, yo en principio no os quería contar mucho más por hoy, por no marearos más tampoco en exceso. 01:36:06

No sé si tenéis alguna duda de todo lo que hemos visto, de alguna otra cosa. Hay dos situaciones. Un poco el concepto entre clase, padre e interfaz. 01:36:19

Pues lo que os he comentado, la clase padre te permite tener desarrollado algunos métodos y algunos abstractos, algunos que le obligas a firmar el contrato de tienes que implementarlo. 01:36:59

Las interfaces no tienes desarrollado ninguno. Es así. Y luego, la herencia, claro, la herencia te resulta muy útil porque puedes utilizar ya código que tienes disponible en la clase padre, mientras que a la hora de implementar los interfaces tienes que desarrollar obligatoriamente los métodos. 01:37:15

pero tienes el inconveniente de que la herencia es única 01:37:39

entonces si tú te ves en la situación de que el alumno en verdad en su definición general 01:37:45

pues tiene que tener las características que tienen las personas 01:37:53

pero además quieres obligar a que cumpla todo lo que tienen que hacer los trabajadores 01:37:56

En las vacaciones, pues tienes que elegir uno como obligatoriamente, uno como clase padre y el resto como interfaces, porque como no nos permite herencia múltiple, si nos permite herencia múltiple, nos olvidábamos de este implements y poníamos esto aquí, poníamos estas clases abstractas y las desarrollábamos. 01:38:02

Pero como no es posible hacer herencia desde diferentes clases, obligatoriamente tienes que hacerlo así. ¿Cuál puedes utilizar de, yo qué sé, en este caso, a ver, a ver, claro, por ejemplo, según el criterio que utilizábamos antes, decíamos, ¿un alumno es una clase de persona? 01:38:22

Y decíamos, sí, ¿os acordáis para la composición y la herencia? ¿Un alumno es una clase de trabajador? Sí. ¿Un alumno es una clase de vacaciones? Pues vacaciones, quedaría un poco raro la herencia de vacaciones, ¿sabes? También, porque no responde un poco a esta pregunta que nos identifica la relación de herencia. 01:38:48

En definitiva, tendrías que elegir una de ellas como clase padre, aquella que te proporcione más código que utilizar desde los métodos que tiene desarrollados y las otras tendrías que utilizarlas como interfaces. 01:39:05

No recuerdo exactamente cómo lo argumentan en el código. Si me das una pista, a lo mejor te puedo... 01:39:21

El concepto en líneas generales, si ahora un poco después de ver el concepto que os cuento, al leerlo de nuevo en el tema no lo entiendes, 01:39:32

pues pon en el foro una pregunta e intento aclarártelo, no sé, dentro de lo que sea capaz te lo intento aclarar, ¿vale? 01:39:46

Pero un poco la idea de base es esta, la herencia es única y te permite tener a tu disposición los métodos desarrollados y te obliga a implementar los abstractos. 01:39:52

Los interfaces directamente tienes que desarrollar todos y eso sí te permite definir diferentes interfaces, 01:40:08

Te permite definir diferentes firmas de, me comprometo a que si soy un alumno e implemento esta interfabia, te voy a disponer de estos métodos desarrollados para que desde otras zonas de código sean capaces de utilizarlos, porque si no he firmado ese contrato, compilaría la clase alumno directamente, aunque no tenga alguno de ellos, como es lógico. 01:40:16

Pero en el momento que pongo esto, ya no me va a compilar, a no ser que tenga todos esos métodos que son candidatos a ser llamador desde clases terceras desde el programa. 01:40:36

ya te digo, un poco con lo que os he contado 01:40:44

que vamos, desde mi punto de vista es como enfocar 01:40:51

la clase abstracta y las interfaces 01:40:54

si vuelves a releer el tema y no entiendes cosas 01:40:56

ponme una consulta ahí en el foro e intento aclararla 01:40:59

porque no me acuerdo, francamente no me acuerdo 01:41:02

como lo describe en el tema, esta parte 01:41:05

vale, bueno pues nada 01:41:08

si no me preguntáis nada más, vamos cerrando 01:41:19

os subo la 01:41:22

tutoría esta por si la queréis echar un ojillo 01:41:25

si os aburrís mucho y tenéis otro rato 01:41:27