Errores comunes al diseñar Interfaces -
Вставка
- Опубліковано 8 вер 2024
- 🔥 ¡Aprovecha la oferta del Black Friday de CodelyTV Pro!
⮕ codely.tv/pro/...
---
¿Cometes alguno de estos errores comunes al interpretar el Principio de Segregación de Interfaces?
En este vídeo veremos principalmente en qué se basa el concepto "las interfaces pertenecen a los clientes que las usan y no a las clases que las implementan". También hablaremos del "acoplamiento estructural" de nuestras interfaces.
Recomiendo darle un voto de confianza a la explicación. Al principio del vídeo creo que me lío un poco y a medida que avanza el vídeo considero que se puede entender mejor lo que quiero transmitir.
hoy 2024, yo teniendo 9 años de experiencia en ing software, y vaya churrazo de video que me esta ayudando, porque yo aprendi esto en base a la practica, y mas en mi ultimo empleo, sin saber que ya estaba usando unos de los principio de SOLID, ahora que estoy en busqueda de empleo, me he percatado que ya tengo otro % mas de lo que requieren, no solo basta con aprender un lenguaje y sus infraestructura, tampoco no solo aprender DSA (que casi nunca lo implemente en todos los trabajos anteriores / casi 9 años), sera que he tenido suerte o sera que aprendi sobre la marcha....
ahora ya conociendo estos conceptos y terminologias, he salido del Sindrome del impostor, es dificil conseguir empleo y mas si tienes este sindrome y viendo el flayer de la oferta laboral tan extensa que piden SOLID, DSA, Cloud, SCRUM, etc etc etc...
y ahora solo estoy reforzando el DSA, y comprendiendo SOLID a profundidad, ya no importa que lenguaje usar, sin querer he aplicado para C# (soy mas experto en python), y no cambia absolutamente nada, solo el como se escribe el lenguaje.
Hace poco descubrí los principios SOLID y las arquitecturas ddd pero tus videos me han ayudado un montón para entender de manera global como el principio de responsabilidad única y el desacoplamiento puede ayudar infinitamente a desarrollos largos o grandes.Gracias.
yo en 2022 estoy leyendo esto y me está ayudando demasiado a entender Spring Boot que utiliza un mazo de interfaces
Un punto importante a mencionar, es que tal y como este principio está descrito en el libro de Clean Architecture, habla más sobre la ventaja que tiene esto en lenguajes de tipado estático. Si multiples clases usan el mismo objecto, pero usan diferentes métodos, cambiar cualquier método, obligara a recompilar todas las clases.
Si ponemos interfaces en medio, para que las clases no puedan ver todos los métodos del objecto, pero en su lugar solo puedan ver los métodos que utilizan, entonces sólo se van a recompilar las clases que se ven afectadas por la modificación de un método.
Creo que este punto es importante para entender porque ISP es diferente a SRP y DIP.
Que gran explicación!!!!!
Por si a alguien le sirve, lo que comentas yo lo veo de esta manera: el que CREA la interfaz es el que la va a usar. Es decir, aunque ya sepamos quién la va a implementar, yo me abstraigo de esa clase que yo sé que voy a usar y sólo pienso "¿qué necesita este servicio para hacer su tarea?" y creo una interfaz olvidándome de la implementación. Si necesito un método save y uno find, creo una interfaz así. Porque es ella la que sabe lo que necesita. El cómo la implementemos viene después. Porque quizá para el save necesitemos llamar a un método flush para persistirlo en la BD. Y eso no le importa al cliente. Para él, save es save, no le importa que luego eso conlleve una lógica por detrás para reducir llamadas a la BD o lo que sea.
Y eso no significa que, en mi ejemplo, se pierda esa lógica del flush. Simplemente que no es tarea del cliente. La clase que contiene la lógica (independiemente de las interfaces que implemente), es la que sabe cómo hacer su trabajo, sea el que sea.
Gracias por el aporte. Excelente el video.
Muchas gracias por la aclaración....excelente video!!!
Yo soy el primero que los cometo jejeje Para mi es un reto pensar que las interfaces pertenecen a los clientes :)
Aprovecho para preguntarte por la arquitectura hexagonal, ¿alguna recomendación para empaparme?
Gracias!
+Armando Antón García :)
Sí. Aquí te dejo una charla que, a pesar de que no es de los primeros que empezaron a hablar de hexagonal ni mucho menos, creo que es en la que mejor se ilustra el concepto. A mi me ha servido mucho y creo que es perfecta para introducir el concepto. Ya sólo con las slides se entiende bastante bien: fideloper.com/hexagonal-architecture
¡Saludos!
+CodelyTV Gracias, apuntado para leerlo pronto
+Armando Antón García Aquí te dejo también la referencia que más comúnmente se cita: alistair.cockburn.us/Hexagonal+architecture :)
Excelente video, se agradecen los tips! Saludos
Creo que el inicio del vídeo lo explicas perfectamente con el ejemplo del coche (aunque los clientes podrían ser un conductor, un copiloto y un mecánico por ejemplo, es más simple que una estación de autobuses). Y al final creo que es un poco lioso porque es como si mezclaras el interfaz que implementas (como cliente de la API de Facebook) con el que extraes que es el que hay que exponer al cliente ... ¿? Pero enhorabuena por el canal, he visto algunos videos y están muy bien.
gracias excelente video
Saludos gracias por tus aportes.... Yo cometía ese error de crear las interface para la implementación, después vi un comentario de alguien en una conferencia,,, que dijo, porque ven las interface para los métodos de implementación y organizarlos, no tendría más sentido ver las interfaces, como el contracto que tiene que aceptar el cliente para poder usar otros objetos? y tu análisis en este video pienso que deja dicho eso,,, las interfaces son el contrato que el cliente debe cumplir para poder usar otras clases u objetos..
Luego conocí el patrón estrategia, que termina de confirmar eso, que básicamente dice: su objetivo es hacer algoritmo intercámbiales y usar el mejor en cada caso, pues aquí, quien usara el algoritmo, sencillo el cliente, y cual usara el que mas le convenga, pero para usarlo debe cumplir con el contracto, tu quieres usar el algoritmo para iniciar sección con Google, pues aquí esta el contracto, quieres usar el algoritmo para iniciar sección con tu propio usuario y contraseña, pues aquí esta el contracto, puedes usarlo pero no necesitas saber como funciona!
El auron de la programacion
cualquiera
Excelente! Me aclaras mucho mi mente!
bobo
Buenas, tienes algún vídeo en el que expliques la creación o el uso de una factoría?
Podria hacer un ejemplo porfavor y darle seguimiento :D ...
+BrabuZ Hoooola!
Aquí tienes el vídeo anterior en el que también hablábamos sobre el ISP: ua-cam.com/video/EzUIbMdxJTk/v-deo.html, aquí la lista de reproducción sobre principios SOLID: ua-cam.com/play/PLZVwXPbHD1KOICjUoGskyREC0VmOGctrm.html, y aquí la lista de reproducción sobre refactoring: ua-cam.com/play/PLZVwXPbHD1KM1rgPP3HymL7ES1v30Fi9B.html
¿Sobre qué te gustaría contar con más ejemplos en concreto?
un ejemplo o una serie de videos que inicie desde cero la creación de un sistemita aplicando lo que explicas en los videos.de esta manera tus videos tendrian mucho mas realce!.:D +1
Si tengo una clase padre y una clase hija estaria aplicando una forma de acoplamiento?. Laravel cumple la arquitectura hexagonal?
Hola Eduardo, a tu primera pregunta: depende, quiero decir que dependerá de la implementación de las clases, no necesariamente tiene que existir acoplamiento si se cumple el SRP, deberías plantearte: "¿Qué motivos hay para cambiar cada una de las clases?" sí para cada clase solo encuentras una razón, quiere decir que cumples SRP entonces probablemente no existirá acoplamiento entre las clases.
Hola, los traits en php serían un antipatron?
Depende mucho. Hacemos un vídeo para comentarlo en breves que será mejor y ponemos ejemplos 🙂
Hola desde el 2022
Que es segregar, que quieres decir con eso?
No hiciste ejemplo bro.