Las interfaces pueden heredar de otras interfaces utilizando la palabra clave extends, el concepto de herencia se aplicará como naturalmente se practica en clases, es decir, la interfaz heredará y adquirirá los métodos de la interfaz padre.
Una cosa interesante que sucede en caso de herencia con interfaces es que, aquí sí es permitido la herencia múltiple como ves a continuación:
Además siguiendo las implementaciones de métodos default y private de las versiones Java 8 y 9 respectivamente podemos sobreescribir métodos y añadirles comportamiento, si es el caso.
publicinterfaceVisualizableextendsIReadable,Serializable{publicvoidsetViewed();publicBooleanisViewed();publicStringtimeViewed();@Overridedefaultvoidread(){// TODO Auto-generated method stub}}
Ahora que estoy en la universidad, en la clase de programacion parte de lo que aprendo a qui, lo veo en la u. Me siento que voy un paso adelante de la clase
Me pasa igual, solo que aquí veo cosas que en todo lo que llevo de la uni, ni siquiera se han hecho mención y son cosas que para mí son básicas para entender el tema
El aprendizaje de platzi es buena y es muy resumida, en ocasiones es bueno investigar,
Y pensar que antes corría de Java porque decía que era demasiado complicado. Quisiera que todos mis profesores de la universidad hubieran tenido el mismo animo que los profesores de Platzi para explicar las cosas
Esto me abre un monton de ideas de como se podria implementar clases "tipo Platzi" en las universidades. En verdad, el enriquecimiento en el conocer del estudiante debe ser la principal prioridad.
Me pregunto cual es el límite de modularidad en la POO.
En las primeras clases se menciona que este paradigma nace de inspiración en el diseño y la arquitectura. Pero en la arquitectura, a cualidad modular de las edificaciones limitó su eficiencia en muchos sentidos, tanto en diseño y lo que en desarrollo se conoce como UX, como en la eficiencia operacional del espacio. A tal grado que actualmente los mejores edificios no expresan esa modularidad, y los que sí la expresan parten de eso para abaratar costos y suelen ser edificios bastante genéricos y mediocres.
Actualmente los edificios más brillantes resuelve las necesidades de un edificio casi creando un paradigma para cada problema a resolver, partiendo de algunos pocos conceptos elementales de estructura y teoría.
Pero esto es diferente, la arquitectura es material y finita y esto se siente que podría ser infinito y me pregunto si eso es bueno o malo.
El límite de la modularidad del software lo pone cada programador de acuerdo al problema que se está resolviendo y a la experiencia del programador, Vaya pedazo de cliché, pero no puede estar más cerca de la realidad.
Al comenzar en la programación uno se agobia con la cantidad de maneras diferentes en las que puedes resolver un problema y conforme vas haciendo tu programa te vas dando cuenta que partes puedes aislar clases diferentes y cuales no. En la construcción imagino que no es posible o si lo es, costaría más tiempo y dinero en comparación con una modificación a un software.
Obviamente antes de comenzar a programar es necesario planear como va a estar organizado tu software, definitivamente es lo mejor, aunque jamás se está exento de crear nuevos módulos o separar en clases que no se tenían planeadas, porque al inicio no se profundiza tanto como para estar completamente exento de modificaciones, quizás por la misma sencillez de crear una clase nueva e integrarla en el proyecto. (Cabe mencionar que no he trabajado en proyecto de software muy grandes, imagino que para el software de un equipo médico o una nave espacial es muy profunda la planeación).
Conforme vas adquiriendo experiencia y te encuentras en un proyecto nuevo, o incluso durante la plática con tu cliente sobre sus necesidades, en mente ya estás dividiendo el software en módulos. Imagino que los chinos que crearon el Edificio de 57 pisos en 19 días, ellos ya tenían muchísima experiencia.
Me gusto tu comentario Paco, me dejo pensando y así va a ser por unos dias. Por otro lado no lo compararia con edificación ya que mi codigo podría ser escalable e ir agregando módulos (modularizarlo más de lo que se había planificado) lo cual a un edificio ya planificado no le puedo ir agregando pisos jaja (aunque en un futuro... quien dice que no). Por ende veo muy valido tu punto de vista de cierto modo.
Excelente. que mundo este !!!
Entiendo lo que se puede hacer con interfaces, pero sigo sin entender para qué sirve o en qué aporta realmente xd.
Generalmente la utilidad es que tienes un esqueleto que previamente tu puedes definir y con esa estructura todas las demás Clases que la usen deberán adaptarse.
Se que mi explicación anterior tal vez siga siendo chino así que mejor te hago este ejemplo: Con JDBC tu puedes conectar a cualquier base de datos, Pero debes seguir unas reglas como implementar el método conect(). De manera que siempre deberas llamar la interfaz principal de JDBC para poder conectarte a la BD indiferente el driver que uses, imagino que esto ultimo permite abstraer mejor para que una interfaz
recuerda el ejemplo de las clases de Nurse, Doctor digamos que nurse y doctor pertenecen a una misma familia de clases debido a la lógica de negocio y por eso tienen un método en común que era schedule() pero este se implementa de forma diferente para ambos pero es el mismo método, es por eso que se abstrae el comportamiento en una interfaz para que cada clase que la implementa lo haga acorde a sus necesidades.
Si se puede hacer herencia múltiple con interfaces, ¿por qué no con clases?
Wow! Primera vez que alguien me responde! :D
Gracias! Muy buen aporte.
Realmente queda mucho mas claro. Lo que en a universidad era un problema ahora se torna una solución
Tendré que investigar más para que me quede más claro.
Esto esta muy chido. Java te AMO!!
Genial, por eso es que JAVA me esta enamorando.
Entiendo que al darle comportamiento y al no obligar su implementación de todos sus metodos, lo correcto sería usar interfaces para abstraer comportamientos y según sea el caso ya no usar clases abstractas.
!que locura! he aprendido mucho con este curso :)
wow que crazy es decir podemos usar la herencia y en este caso la herencia mutiple pero nace la curiosidad por que en este aso si nos dejan aplicar la herencia multiple y con las clases no ya que java nos dice que en clases no es posible por el problema diamante pero con las interfaces no esto es debido a que con una heredamos atributos y con otras parámetros pero dando una respuesta mas profunda y no tan simple es debido a que las interfaces establecen una firma o parámetros pero no como usarlos y en cambio a las clases es todo lo contrario y se hace en el Problem diamante
pero entonces como es que evitamos el "diamante " es debido a que este es mas flexible y no cuenta con metodo dentro de este es decir solo tiene firma no cuerpo.por tal no se cae en esta ambigüedad
🤔 Nuestras interfaces también pueden heredar de otras, haciendo posible la herenciamúltiple.
Es curioso que yo me adelanté a ver un curso de srping MVC antes de estos y en cada clase voy entendiendo mucho más el uso de las interfaces y su herencia. <3
excelente explicación
Realmente interesante
Cada día que veo este curso me gusta mas java, tiene multiples formas de plazmar soluciones
una forma muy dinámica de sobre inscribir un método :)