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.
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?
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
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
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.
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.
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...
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 😋
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?
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.
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!!
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.
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.
En lo personal no me gusta, porque cuando un sistema crece mucho, se vuelve un spaguetti enorme de clases y a la hora de heredar el codigo esta parte se vuelve compleja.
Que genios son los argentinos, definitivamente son los que mejor explican. Saludos desde argentina
opino igual. Saludos desde argentina
El mejor por lejos de todos los videos que vi explicando SOLID. Un groso!!!
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,
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.
Muchas gracias por la información! Muy claros los ejemplos !
Muy buena explicación! De las más claras que he visto 😉
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
¡Excelente video, gracias por el aporte!
Excelentemente explicado! Felicidades.
Muchas gracias siempre me encanta este tipo de contenido y explicado de una manera muy buena
Excelente la explicación, son un vicio tus videos por la claridad con la que explicas cada tema
Contenido de alta calidad como siempre, practicamente esas preguntas me las plantearon en una entrevista laboral :)
Muchas gracias Moroni y saludos
Excelente explicación!
Muchas gracias, excelente esplicación con casos practicos.
Muy buena explicación, muchas gracias.
Uno de los mejores videos explicativos que he visto. Excelente y muchisimas gracias por la gran semantica al explicar
Muy bien explicado, gracias! Definitivamente voy a profundizar aún más en todo esto
Enhorabuena por el vídeo. Es sencillo de entender y lo explicas bien.
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 😊
Wow, increíble esta explicación, mil gracias!
Buenisimo! que buena explicación ciertamente se entiendo mucho mejor cuando se hace de forma practica mas que viendo la teoria! un éxito :)
Excelente forma de explicar, muchas gracias!
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!
Excelente video maestro...Excelente!! Muchas gracias por compartir !!1
Muy bien explicado. Gracias
Me ha sido de mucha utilidad. Muchas gracias!
Que buen contenido. Super claro y didáctico todo. Me suscribo! Saludos
Excelente!! despues de tanto buscar información, tu explicación me clarifico todas las dudas de SOLID, muchas gracias. ✌
Muy bien explicado. Gracias. Saludos desde México.
Excelente explicación me está comenzando a quedar claro, ya me suscribí
Excelente video. Este es un vídeo que voy a ver varias veces hasta tenerlo bien grabado en la cabeza. Muchas gracias!!!!
Diosss mio excelente al fin algo sencillo pero poderoso y que explica los principios con practica
Muchas gracias , me has salvado , despues de tanta documentación por fin algo practico con problema y solución , 10 de 10 estimado.
Muy buena la explicación, muchas gracias
Gracias, muy clara la explicación :D
Muy buen vídeo, muy practico!
Muy practico, me encantó
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?
Gracias de nuevo por tus videos! saludos
Muy buen video! Gracias
Excelente explicación con problema y solución!
Brutal Crack, muchas gracias por la explicación y el aporte ;-)
Excellent.
Buenisimo video completamente..! muy bien explicado la verdad lo entendi mejor
Gracias genio!
Genio, gracias
Extraordinaria y Didactica explicacion.Lo hiciste facil de entender Felicitaciones bro😊
Excelente!
Buena explicación, todos estos prinicipios lo relaciono mucho con el patrón de diseño inyección de dependencias
eres el mejor, gracias
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?
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.
Maestro gran contenido
muy bueno el video amigo
Exelente video bro
Suscrito :), gracias por la informacion
suscrito! :) gracias!
Muy bien explicado todo!, Genial!!.... esta solución se encuentra en algun repositorio GIT? me gustaría obtenerla para utilizarla como material de estudio
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
Hola!, genial la explicación junto a los ejemplos. Será posible que compartas el repo de este ejemplo?, gracias!!!
Buenismo ... nos vino barbaro para una clase ...
Me encanta este canal no se tu nombre pero ya te amo
Gracias ;-)
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.
Genioooo yo estoy suscripto hace tiempo te dejo like y comentario en tus videos! Gracias por subir contenido de calidad
Muchas gracias Ariel! 😊
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 :)
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
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?
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.
Excelente video muchas gracias, ahora necesito el de las críticas para saber el por qué 🥴
Crack. Entendible con los ejemplos. El link del servidor de Discord no está...
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.
hola amigo, como estas? me puedes pasar el link del codigo fuente para descargar por favor
Hola, sse pueden descargar los ejemplos de algun lado? Muchas gracias
Excelente explicación, muchas gracias
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 😋
Dónde podemos leer o ver los argumentos de quienes no usan solid por favor? Gracias de antemano.
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?
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 ! :)
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.
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.
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!!
Por ahí ultimadamente en los principios Solid agregaron una mas la ley de Demeter...
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.
Para liskov que pasa si el lenguaje de programación no tiene interfaces 😂?
lo malo que entre mas complejo una app asi seria la cantidad de proyectos y archivos
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.
Entendí pero vas muy rapido especialmente para los q no manejamos cs
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.
Salaverga que basado
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.
En lo personal no me gusta, porque cuando un sistema crece mucho, se vuelve un spaguetti enorme de clases y a la hora de heredar el codigo esta parte se vuelve compleja.
No sabés programar entonces, tu nivel siempre va a ser bajo.
Excelente explicación!
Excelente!