Muy bueno el video, el unico detalle es en el Principio de sustitución de Liskov. Lo solucionaste usando interfaces, que esta bien y es una solucion, pero la solucion del principio va arraigado a sustituir a las clases padres por los hijos, es decir, aplicando herencia a la solucion.
Me ha gustado mucho el vídeo. El único principio que no veo claro es el de Liskov. Es cierto que la solución que das no inclumple el principio, pero, ¿no se supone que trata de herencia? Una clase padre Vehicle con los métodos comunes a todos los vehículos y otras clases hijas con métodos específicos, tampoco lo incumplirían, ¿no? (aunque pueda seguir siendo preferible por otras razones tu solución). Un saludo y ¡muchas gracias por el vídeo!
Pensaba lo mismo. Hubiera hecho de forma explícita la sustitución de un tipo base por su tipo derivado, cumpliendo el principio (gracias a las interfaces) y corroborando que el programa no se rompe.
Tienes toda la razón, ese principio consiste en usar herencia para resolverlo. En el ejemplo que ha puesto habría una clase VehículoVolador con los métodos específicos. De forma que coche y moto heredarían de Vehículo sólo.
@@jay-fs Exacto, VehiculoVolador hereda de Vehiculo que es el padre base que SOLO y UNICAMENTE deberia de tener las funciones puras de un vehiculo, si quicieramos que tenga la funcion de volar, haces otra clase VehiculoVolador : Vehiculo , Entonces finalmente podrias hacer una moto voladora o algo del estilo haciendo var Moto = new VehiculoVolador(), donde que moto heredaria de vehiculo, por ende el principio de que los hijos pueden sustituir a los padres se cumple
Excelente. Sos el que mejor explica, sos muy claro y fluido para hablar, virtud está última que no muchos tienen. Una consulta sobre el LSP: si estoy seguro que algunos comportamientos si o si van a tenerlo todas las clases que hereden, por ej si en este ejemplo de vehículo sería "acelerar", ¿rompería el principio que lo deje dentro de una clase abstracta, y a la vez que las clases hijas hereden de esta clase abstracta, implementen mediante interfaces los demás métodos que no son para todas?
Muy bien explicado todo!, Genial!!.... esta solución se encuentra en algun repositorio GIT? me gustaría obtenerla para utilizarla como material de estudio
cada vez que veo un video tuyo es terrible lo que me queda en claro. A veces se da tanta vueltas para explicar algo, y verlo de esta manera es magnífico.
Excelentes tus videos crack, de verdad que tienes una manera de explicar y llevarlo a la práctica que hace que se entienda, todo un profe, ahora cuando voy a las aplicaciones reales en mi trabajo, cuesta entender si están haciendo de manera correcta o siguiendo estos principios jaja. Podrías compartir este proyecto?
Tengo una duda: en el tercer principio, al reemplazar la herencia por implementación de interfaces, ¿cómo validarías que las clases derivadas al reemplazarse por su clase base sigan funcionando? Dado que ya no existe la clase vehículo
Siempre he escuchado de los principios solid pero nunca había profundizado en saber lo que eran. Tras ver el vídeo, veo que muchas cosas ya las aplico de forma inconsciente (solo hay que usar un poco la lógica) aunque no me acaba de gustar al 100% la manera en el que se abordan algunos problemas con estos principios. Después, algún principio no lo entiendo, por ejemplo, el de “Liskov substitution principle” en el que se dice que “las clases derivadas deben poder sustituirse por sus clases base”. Qué tiene esto que ver con definir una clase e implementar una o más interfaces? No hay clase base ni derivada por ningún lado. Me parece que esto es más otra “moda” a exigir en las entrevistas de trabajo que algo realmente útil en la vida real (al final todo es aplicar un poco de sentido común e inyectar dependencias). De todas formas buena explicación en el vídeo.
El principio de sustitución aquí está mal explicado, precisamente por lo que comentas, por que no hay herencia ninguna simplemente está implementando interfaces, es decir, no hay sustitución alguna 🤣 En el canal de HDLEON tienes una mejor explicación no puedo pasarte el link me eliminan el comentario. Básicamente cuando una clase hijo no puede usar ciertos métodos de la clase padre(abstracta), lo que se debe de hacer es quitar esos métodos de la clase abstracta e implementarlos en una nueva clase, y después las clases que necesiten de esos métodos heredar de la nueva clase que a su vez hereda de la abstracta, soy muy malo explicando estas cosas, lo entenderás mejor si ves el video de hdleon, un saludo.
Tengo una pregunta, en el tercer principio de la sustitución de Liskov, si era necesario crear interfaces?, porque creo yo que con la implementación de cada clase BurgerOrderService, SteakOrderService y SaladOrderService, se podia definir el funcionamiento dentro del cuerpo de esas clases sin tener que llamar a las interfaces, es una duda, y quiero entender mejor esta parte gracias.
en resumen, los principios solid son lo mismo que venimos haciendo de siempre usando patrones tradicionales y buen modelado, solo que a alguien se le ocurrió ponerle un nombre marketinero y, de alguna forma, logró popularizarlo. S: POO O: strategy pattern L: subclass responsibility I: O + L D: arguments como dices en la última parte del video, lo importante a saber es que todo esto (principios, arquitecturas, patrones) son conceptos teóricos, y no siempre aplican para una solución, o aplican parcialmente. hay que saber cómo y cuándo usar cada uno de estos conceptos, y no ser puristas. por ejemplo, tratando de implementar el "principio de responsabilidad única" se podría caer en un abuso de clases con uno o dos métodos, que complicarían muchísimo el diseño total. y así con tantas otras cosas. todo debe apuntar a tener un mejor diseño, pero si el resultado es un peor diseño, es que el principio no aplica o no era necesario aplicarlo. hay que ser criteriosos.
Excelente explicacion de los principios SOLID, solo una duda, con estos principios no se puede caer en el error de generar demasiadas clases o interfaces extras?
Depende, por ejemplo el de abierto cerrado es mejor no aplicarlo mientras está creciendo una clase. Es decir, si estás en el desarrollo inicial. Una vez que si que ya la termines y haga todo lo que tiene que hacer, si a futuro llega algo nuevo, es cuando podrías crear otra clase. Así mantienes el código antiguo que está debería estar testeado sin que se vea afectado por los nuevos cambios. De todas formas el "mejor principio" es test unitarios everywhere 😋
Buen video! Tengo una duda. No acabo de comprender el tercer principio, entonces cual es la gracia de la herencia si es mejor implementar las funcionalidades mediante interfaces??
A mí parecer no está bien explicado ese principio. Te pongo una situación que seguro has visto. Cuándo heredas de una clase padre que no sea abstracta y tienes un método doWork() y ese método lo sobreescribes con otra clase heredada. Y nunca llamas el método doWork de la clase base. Allí estas violando expresamente ese principio.
Haces una excelente labor! Ya he comprado dos cursos tuyos en Udemy, con eso apoyo tu canal y el esfuerzo que haces, sigue asi amigo, tienes un seguidor más pendiente a lo que subes...
En la explicación de Liskov no se muestra como Bike puede reemplazar a Vehicle (de hecho por lo que veo no puede, porque le faltarían métodos), que es justamente lo que propone el principio. No se si es el mejor ejemplo, al final bike no es hija de Vehicle, entonces el principio se cumple ok, pero porque son totalmente diferentes, asi cualquiera cumple. Lo importante es ver como esto funciona a traves de la herencia.
Buenas, ha llovido largo desde la creación del video y sigue dando de qué hablar. Buen video. Tengo una duda con el segundo principio, Open-Closed. Dices que no se use el if para crear el tipo de report a generar, pero entonces, si el tipo lo sacamos de un combo que selecciona el usuario, tendremos que crear en esta función, y en todas en las que se llame a la generación de este report, ese if. O en su defecto implementar una Class Factory que lo discrimine, pero creo que das a entender que el if desaparece, y no tiene porqué... ¿Me equivoco?
Copié todo el código, pero tuve un compiler Error CS0051, que se resolvió en la clase OrderService porque la puse como public en lugar internal. ¿por qué esto sucede? Todas las demás clases están como públicas.
Un detalle: En el OPC, pasamos una LISTA de ordenes cuando deberíamos de pasarlo como IEnumerable para mantener su inmutabilidad y no permitir que se le añadan más ordenes!!
Lo bueno del video es que explica los principios con ejemplos para entender mejor pero, por que poner el nombre de las clases e intefaces en ingles, si fueran en español se entenderia mucho mas, no digo que sea muy dificil ver de que se tratan las clases asi como estan en ingles pero seria mucho mas facil de entender y mas rapido lo que se esta explicando, aparte el video esta en español no entiendo porque poner el nombre de las clases en ingles.
Todo está muy bien con la explicación, nada que objetar. Pero hay una cosa que no logro entender: Al separar las funcionalidades en sus clases propias, lo único que realmente se está haciendo es crear object wrappers que envuelven funciones (en este caso métodos). Cada uno de estos métodos tranquilamente pueden ser simplemente funciones o sub-rutinas (o como los quieran llamar), y ya no habrá necesidad de meterlos dentro de una clase, implementarlos, extenderlos, etc. Repito, la explicación está muy bien, el código es muy lindo y todo eso, pero, no hay que llamar Programación Orientada a Objetos simplemente por agarrar una función y meterla dentro de una clase, ¿para qué hacer eso? Es más, los object wrappers de esas funciones ni siquiera definen propiedades dado que los parámetros de esas funciones (convertidas a métodos) provienen desde fuera de su clase contenedora, lo que nos da la pauta de que indiscutiblemente estamos ante una simple invocación a una función, y creando un constructor realmente no cambia este concepto. Por último, las funciones tienen ámbito global, lo que quiere decir que podemos llamarmas desde cualquier lugar del área de ejecución del código (contexto), entonces, por qué no simplemente crear funciones y meterlas en sus correspondientes archivos, y cargarlas sólo cuando se invocan. Si una clase posee 1 solo método y la clase no impleneta propiedades, y este único método recibe parámetros por medio de un constructor, entonces hay que deshacer la clase y convertir ese único método en una función en solitario y que valide sus propios argumentos.
Y una ultimisima cosa que se me olvidó mencionar: Veo muchas veces que se crean clases abstractas, y estas clases abstractas definen interfaces a ser implementadas por las clases concretas que heredan de ella. La clase abstracta define propiedades, y define un constructor que servirá de puerta de entrada para los datos, luego, la clase concreta implementa la interfaz y fin del cuento. Entonces díganme ustedes: ¿acaso esto no es claramente una simple función que por estar dentro de una clase se convierte en un método que introduce parámetros por medio del constructor de su clase de la cual deriva, y que internamente éste método implementa su lógica (código) que puede o no retornar un resultado? La pregunta es retórica. Eso de meter funciones dentro de clases para convertirlas en métodos de su objeto es un mal uso de la POO. Y es justamente eso lo que ocurre con los principios S.O.L.I.D. Simplemente fíjense con detenimiento.
Eres de la vieja escuela que aprendió a programar con programación estructurada, como yo jejeje. O sea tiene mucho sentido lo que argumentas. Vivimos en una época en la que nos venden que ya no se use herencia que lo mejor es la composición, después que tanto nos costó programar orientado a objetos precisamente por entender los conceptos de herencia. XD entre otros. Entonces está la pugna entre programación funcional y objetos para rematar.
Que genios son los argentinos, definitivamente son los que mejor explican. Saludos desde argentina
opino igual. Saludos desde argentina
Muy bueno el video, el unico detalle es en el Principio de sustitución de Liskov. Lo solucionaste usando interfaces, que esta bien y es una solucion, pero la solucion del principio va arraigado a sustituir a las clases padres por los hijos, es decir, aplicando herencia a la solucion.
También lo noté, hubo una confusión en el concepto de ese principio
En realidad no lo explico bien a mi parecer,
Impecable! La mejor explicación que encontré en términos de teoria/ejemplos. Mil gracias
En el único vídeo que me he enterado bien de los principios, nada como unos buenos ejemplos prácticos y no tanta teoría. Un 10.
El mejor por lejos de todos los videos que vi explicando SOLID. Un groso!!!
Buenisimo! que buena explicación ciertamente se entiendo mucho mejor cuando se hace de forma practica mas que viendo la teoria! un éxito :)
que alegria, solo tu video me ha hecho entender!
¡Excelente explicación, gracias!
Buenísimo el vídeo maestro. Días intentando entender estos principios y con tu vídeo lo he pillado en 20 mins. Mil gracias 😊
Me ha gustado mucho el vídeo. El único principio que no veo claro es el de Liskov. Es cierto que la solución que das no inclumple el principio, pero, ¿no se supone que trata de herencia? Una clase padre Vehicle con los métodos comunes a todos los vehículos y otras clases hijas con métodos específicos, tampoco lo incumplirían, ¿no? (aunque pueda seguir siendo preferible por otras razones tu solución).
Un saludo y ¡muchas gracias por el vídeo!
Pensaba lo mismo. Hubiera hecho de forma explícita la sustitución de un tipo base por su tipo derivado, cumpliendo el principio (gracias a las interfaces) y corroborando que el programa no se rompe.
Tienes toda la razón, ese principio consiste en usar herencia para resolverlo. En el ejemplo que ha puesto habría una clase VehículoVolador con los métodos específicos. De forma que coche y moto heredarían de Vehículo sólo.
@@jay-fs Exacto, VehiculoVolador hereda de Vehiculo que es el padre base que SOLO y UNICAMENTE deberia de tener las funciones puras de un vehiculo, si quicieramos que tenga la funcion de volar, haces otra clase VehiculoVolador : Vehiculo , Entonces finalmente podrias hacer una moto voladora o algo del estilo haciendo var Moto = new VehiculoVolador(), donde que moto heredaria de vehiculo, por ende el principio de que los hijos pueden sustituir a los padres se cumple
Excelente. Sos el que mejor explica, sos muy claro y fluido para hablar, virtud está última que no muchos tienen. Una consulta sobre el LSP: si estoy seguro que algunos comportamientos si o si van a tenerlo todas las clases que hereden, por ej si en este ejemplo de vehículo sería "acelerar", ¿rompería el principio que lo deje dentro de una clase abstracta, y a la vez que las clases hijas hereden de esta clase abstracta, implementen mediante interfaces los demás métodos que no son para todas?
Muchas gracias , me has salvado , despues de tanta documentación por fin algo practico con problema y solución , 10 de 10 estimado.
Excelente explicación!
Saludos, excelente explicación, con esto resolve muchisimas dudas que tenia, podrias compartir el codigo ?
Estaría bueno que publicara el código para poder leerlo detenidamente y navegar cada fuente para aprender.
Diosss mio excelente al fin algo sencillo pero poderoso y que explica los principios con practica
Excelente explicacion !!!
Muy bien explicado todo!, Genial!!.... esta solución se encuentra en algun repositorio GIT? me gustaría obtenerla para utilizarla como material de estudio
Buena explicación, todos estos prinicipios lo relaciono mucho con el patrón de diseño inyección de dependencias
Buenisimo video completamente..! muy bien explicado la verdad lo entendi mejor
Clarísimo... te felicito !!! muy buen video. En el minuto 14:50 se podría utilizar el metodo TakeOff y Land si fuese una motocross... jajaja
Muy bien explicado. Gracias. Saludos desde México.
Excelente explicación con problema y solución!
Uno de los mejores videos explicativos que he visto. Excelente y muchisimas gracias por la gran semantica al explicar
Excelente video. Este es un vídeo que voy a ver varias veces hasta tenerlo bien grabado en la cabeza. Muchas gracias!!!!
Extraordinaria y Didactica explicacion.Lo hiciste facil de entender Felicitaciones bro😊
Muy buen video. Como sugerencia, estaría bueno mostrar el código aprovechando las mejoras de sintaxis de C# 10 en cuanto a global usings y namespaces.
se
Excelentemente explicado! Felicidades.
Lejos la mejor explicación! si bien ya sabía algunas cosas pero me sacaste dudas y ahora puedo decir q lo entiendo un poco más!
Muy bien explicado, gracias! Definitivamente voy a profundizar aún más en todo esto
Excelente explicación me está comenzando a quedar claro, ya me suscribí
Excelente!! despues de tanto buscar información, tu explicación me clarifico todas las dudas de SOLID, muchas gracias. ✌
Excelente forma de explicar, muchas gracias!
Muy bien explicado. Gracias
Muchas gracias, excelente esplicación con casos practicos.
Me ha sido de mucha utilidad. Muchas gracias!
Enhorabuena por el vídeo. Es sencillo de entender y lo explicas bien.
Excelente video maestro...Excelente!! Muchas gracias por compartir !!1
Muy buena la explicación, muchas gracias
Gracias de nuevo por tus videos! saludos
cada vez que veo un video tuyo es terrible lo que me queda en claro. A veces se da tanta vueltas para explicar algo, y verlo de esta manera es magnífico.
Muchas gracias por tu comentario! Me alegro el día :)
CLARISIMO !!!
Excelentes tus videos crack, de verdad que tienes una manera de explicar y llevarlo a la práctica que hace que se entienda, todo un profe, ahora cuando voy a las aplicaciones reales en mi trabajo, cuesta entender si están haciendo de manera correcta o siguiendo estos principios jaja. Podrías compartir este proyecto?
Maestro gran contenido
eres el mejor, gracias
Muy buen vídeo, muy practico!
Excellent.
Buenismo ... nos vino barbaro para una clase ...
Gracias genio!
Muy practico, me encantó
Contenido de alta calidad como siempre, practicamente esas preguntas me las plantearon en una entrevista laboral :)
Muchas gracias Moroni y saludos
Muy buen video! Gracias
Excelente la explicación, son un vicio tus videos por la claridad con la que explicas cada tema
Excelente explicación, muchas gracias
Wow, increíble esta explicación, mil gracias!
Muy buena explicación! De las más claras que he visto 😉
Hola!, genial la explicación junto a los ejemplos. Será posible que compartas el repo de este ejemplo?, gracias!!!
Me encanta este canal no se tu nombre pero ya te amo
Muchas gracias por la información! Muy claros los ejemplos !
Tengo una duda: en el tercer principio, al reemplazar la herencia por implementación de interfaces, ¿cómo validarías que las clases derivadas al reemplazarse por su clase base sigan funcionando? Dado que ya no existe la clase vehículo
¡Excelente video, gracias por el aporte!
Muchas gracias siempre me encanta este tipo de contenido y explicado de una manera muy buena
suscrito! :) gracias!
Que buen contenido. Super claro y didáctico todo. Me suscribo! Saludos
Genio, gracias
Gracias, muy clara la explicación :D
muy bueno el video amigo
Excelente explicación y ejemplos, a lo mejor podrías en otro vídeo hablar sobre las críticas de por qué no usar estos principios, Saludos.
Suscrito :), gracias por la informacion
Excelente!
Exelente video bro
Siempre he escuchado de los principios solid pero nunca había profundizado en saber lo que eran.
Tras ver el vídeo, veo que muchas cosas ya las aplico de forma inconsciente (solo hay que usar un poco la lógica) aunque no me acaba de gustar al 100% la manera en el que se abordan algunos problemas con estos principios.
Después, algún principio no lo entiendo, por ejemplo, el de “Liskov substitution principle” en el que se dice que “las clases derivadas deben poder sustituirse por sus clases base”. Qué tiene esto que ver con definir una clase e implementar una o más interfaces? No hay clase base ni derivada por ningún lado.
Me parece que esto es más otra “moda” a exigir en las entrevistas de trabajo que algo realmente útil en la vida real (al final todo es aplicar un poco de sentido común e inyectar dependencias).
De todas formas buena explicación en el vídeo.
El principio de sustitución aquí está mal explicado, precisamente por lo que comentas, por que no hay herencia ninguna simplemente está implementando interfaces, es decir, no hay sustitución alguna 🤣
En el canal de HDLEON tienes una mejor explicación no puedo pasarte el link me eliminan el comentario.
Básicamente cuando una clase hijo no puede usar ciertos métodos de la clase padre(abstracta), lo que se debe de hacer es quitar esos métodos de la clase abstracta e implementarlos en una nueva clase, y después las clases que necesiten de esos métodos heredar de la nueva clase que a su vez hereda de la abstracta, soy muy malo explicando estas cosas, lo entenderás mejor si ves el video de hdleon, un saludo.
no me queda claro en el Liskov Sustitution me suena mas al cuarto, tal vez
Genioooo yo estoy suscripto hace tiempo te dejo like y comentario en tus videos! Gracias por subir contenido de calidad
Muchas gracias Ariel! 😊
Tengo una pregunta, en el tercer principio de la sustitución de Liskov, si era necesario crear interfaces?, porque creo yo que con la implementación de cada clase BurgerOrderService, SteakOrderService y SaladOrderService, se podia definir el funcionamiento dentro del cuerpo de esas clases sin tener que llamar a las interfaces, es una duda, y quiero entender mejor esta parte gracias.
en resumen, los principios solid son lo mismo que venimos haciendo de siempre usando patrones tradicionales y buen modelado, solo que a alguien se le ocurrió ponerle un nombre marketinero y, de alguna forma, logró popularizarlo.
S: POO
O: strategy pattern
L: subclass responsibility
I: O + L
D: arguments
como dices en la última parte del video, lo importante a saber es que todo esto (principios, arquitecturas, patrones) son conceptos teóricos, y no siempre aplican para una solución, o aplican parcialmente. hay que saber cómo y cuándo usar cada uno de estos conceptos, y no ser puristas.
por ejemplo, tratando de implementar el "principio de responsabilidad única" se podría caer en un abuso de clases con uno o dos métodos, que complicarían muchísimo el diseño total. y así con tantas otras cosas. todo debe apuntar a tener un mejor diseño, pero si el resultado es un peor diseño, es que el principio no aplica o no era necesario aplicarlo. hay que ser criteriosos.
Excelente explicacion de los principios SOLID, solo una duda, con estos principios no se puede caer en el error de generar demasiadas clases o interfaces extras?
Eso me preguntaba yo también, ya que otros recomiendan como buenas prácticas no hacer tantas clases e interfaces divididas.
Depende, por ejemplo el de abierto cerrado es mejor no aplicarlo mientras está creciendo una clase. Es decir, si estás en el desarrollo inicial. Una vez que si que ya la termines y haga todo lo que tiene que hacer, si a futuro llega algo nuevo, es cuando podrías crear otra clase. Así mantienes el código antiguo que está debería estar testeado sin que se vea afectado por los nuevos cambios. De todas formas el "mejor principio" es test unitarios everywhere 😋
Gracias ;-)
Crack. Entendible con los ejemplos. El link del servidor de Discord no está...
Buen video! Tengo una duda. No acabo de comprender el tercer principio, entonces cual es la gracia de la herencia si es mejor implementar las funcionalidades mediante interfaces??
A mí parecer no está bien explicado ese principio. Te pongo una situación que seguro has visto. Cuándo heredas de una clase padre que no sea abstracta y tienes un método doWork() y ese método lo sobreescribes con otra clase heredada. Y nunca llamas el método doWork de la clase base. Allí estas violando expresamente ese principio.
que requisitos previos debo tener para aprender los principios solid? Y tambien que se aprende primero los principios solid o los patrones de diseño?
Haces una excelente labor! Ya he comprado dos cursos tuyos en Udemy, con eso apoyo tu canal y el esfuerzo que haces, sigue asi amigo, tienes un seguidor más pendiente a lo que subes...
Gracias por el apoyo!
@@TheCoderCave necesito los enlaces de esos cursos, por favor.
En la explicación de Liskov no se muestra como Bike puede reemplazar a Vehicle (de hecho por lo que veo no puede, porque le faltarían métodos), que es justamente lo que propone el principio. No se si es el mejor ejemplo, al final bike no es hija de Vehicle, entonces el principio se cumple ok, pero porque son totalmente diferentes, asi cualquiera cumple. Lo importante es ver como esto funciona a traves de la herencia.
Buenas, ha llovido largo desde la creación del video y sigue dando de qué hablar. Buen video.
Tengo una duda con el segundo principio, Open-Closed. Dices que no se use el if para crear el tipo de report a generar, pero entonces, si el tipo lo sacamos de un combo que selecciona el usuario, tendremos que crear en esta función, y en todas en las que se llame a la generación de este report, ese if. O en su defecto implementar una Class Factory que lo discrimine, pero creo que das a entender que el if desaparece, y no tiene porqué... ¿Me equivoco?
Excelente video muchas gracias, ahora necesito el de las críticas para saber el por qué 🥴
Hola, sse pueden descargar los ejemplos de algun lado? Muchas gracias
Dónde podemos leer o ver los argumentos de quienes no usan solid por favor? Gracias de antemano.
Copié todo el código, pero tuve un compiler Error CS0051, que se resolvió en la clase OrderService porque la puse como public en lugar internal. ¿por qué esto sucede? Todas las demás clases están como públicas.
Podrías compartir el código por favor .
Hola, gracias por el video. Pero sigo sin ver la diferencia entre el 3 y 4 principio.
¿Alguien sabe de algun repo que sirva para practicar estos principios ? Saludos ! :)
hola amigo, como estas? me puedes pasar el link del codigo fuente para descargar por favor
Por ahí ultimadamente en los principios Solid agregaron una mas la ley de Demeter...
Podrias compartir el codigo, por favor.
Un detalle: En el OPC, pasamos una LISTA de ordenes cuando deberíamos de pasarlo como IEnumerable para mantener su inmutabilidad y no permitir que se le añadan más ordenes!!
Para liskov que pasa si el lenguaje de programación no tiene interfaces 😂?
Lo bueno del video es que explica los principios con ejemplos para entender mejor pero, por que poner el nombre de las clases e intefaces en ingles, si fueran en español se entenderia mucho mas, no digo que sea muy dificil ver de que se tratan las clases asi como estan en ingles pero seria mucho mas facil de entender y mas rapido lo que se esta explicando, aparte el video esta en español no entiendo porque poner el nombre de las clases en ingles.
Todo está muy bien con la explicación, nada que objetar. Pero hay una cosa que no logro entender:
Al separar las funcionalidades en sus clases propias, lo único que realmente se está haciendo es crear object wrappers que envuelven funciones (en este caso métodos).
Cada uno de estos métodos tranquilamente pueden ser simplemente funciones o sub-rutinas (o como los quieran llamar), y ya no habrá necesidad de meterlos dentro de una clase, implementarlos, extenderlos, etc.
Repito, la explicación está muy bien, el código es muy lindo y todo eso, pero, no hay que llamar Programación Orientada a Objetos simplemente por agarrar una función y meterla dentro de una clase, ¿para qué hacer eso?
Es más, los object wrappers de esas funciones ni siquiera definen propiedades dado que los parámetros de esas funciones (convertidas a métodos) provienen desde fuera de su clase contenedora, lo que nos da la pauta de que indiscutiblemente estamos ante una simple invocación a una función, y creando un constructor realmente no cambia este concepto.
Por último, las funciones tienen ámbito global, lo que quiere decir que podemos llamarmas desde cualquier lugar del área de ejecución del código (contexto), entonces, por qué no simplemente crear funciones y meterlas en sus correspondientes archivos, y cargarlas sólo cuando se invocan.
Si una clase posee 1 solo método y la clase no impleneta propiedades, y este único método recibe parámetros por medio de un constructor, entonces hay que deshacer la clase y convertir ese único método en una función en solitario y que valide sus propios argumentos.
Y una ultimisima cosa que se me olvidó mencionar:
Veo muchas veces que se crean clases abstractas, y estas clases abstractas definen interfaces a ser implementadas por las clases concretas que heredan de ella. La clase abstracta define propiedades, y define un constructor que servirá de puerta de entrada para los datos, luego, la clase concreta implementa la interfaz y fin del cuento. Entonces díganme ustedes:
¿acaso esto no es claramente una simple función que por estar dentro de una clase se convierte en un método que introduce parámetros por medio del constructor de su clase de la cual deriva, y que internamente éste método implementa su lógica (código) que puede o no retornar un resultado?
La pregunta es retórica.
Eso de meter funciones dentro de clases para convertirlas en métodos de su objeto es un mal uso de la POO. Y es justamente eso lo que ocurre con los principios S.O.L.I.D. Simplemente fíjense con detenimiento.
Eres de la vieja escuela que aprendió a programar con programación estructurada, como yo jejeje. O sea tiene mucho sentido lo que argumentas. Vivimos en una época en la que nos venden que ya no se use herencia que lo mejor es la composición, después que tanto nos costó programar orientado a objetos precisamente por entender los conceptos de herencia. XD entre otros. Entonces está la pugna entre programación funcional y objetos para rematar.
Entendí pero vas muy rapido especialmente para los q no manejamos cs
lo malo que entre mas complejo una app asi seria la cantidad de proyectos y archivos
Barbara Liskov no se ha muerto, no "era", "ES".
Gran dato porque realmente no sabía!
Simplemente asumí que ya no estaba viva. Gracias por la aclaración.
Salaverga que basado