Gran explicación, tengo una duda con relación al principio , Si digamos que tengo una clase Persona y así mismo tengo dos clases más que serían , cliente y proveedor los cuales tendrían los mismo atributos que persona más algunos atributos propios de ellos, En ese caso si mi clase Cliente y Proveedor heredan de Persona, digamos para ahorrarme código, estaría violando el principio? Ya que Proveedor no sería igual a Persona al tener más atributos ,en ese caso como lo solucionaría ? Espero tu respuesta, gracias gran video
Hola buenas, si te he entendido bien, lo que tienes es tu clase persona, la cual es común para ambas clases. Tu caso de heredar de persona esta bien, hasta cierto punto. pero hoy en dia se recomienda mas un patron de composición sobre la herencia utilizando el patron abierto cerrado. Lo que quiero decir es que Persona, deberia ser un atributo dentro de cada una de las clases. En el único caso donde yo personalmente heredo de clases es cuando tengo una clase base en común para muchas otras clases, en ese caso lo que haria sería una clase abstracta. Pero si, en tu caso, Persona deberia ser un atributo de cada una de las clases, tanto cliente como proveedor.
Oh cierto el principio de Open / Close , aún no me habia quedado claro del todo por lo que veo! Muchas gracias , soy un estudiante de ingeniería y ahora mismo estoy desarrollando un proyecto para mí clase de programacion, entonces me había estado dando vueltas eso por estos días, gracias por pronta respuesta !
No me parece buen ejemplo porque partes de la base de que SQL herede de Fichero. Y eso es un error. Ambas clases deberían ser, conceptualmente, hijas de una misma base, o mejor aún, de un interfaz. En cualquier caso, hermanas. Pero no padre/hija.
no se si has visto el vídeo entero, pero la idea del vídeo es presentar el porqué necesitamos Liskov y luego mostrar el caso de uso. Por ejemplo, menciono que tenemos una aplicacion X la cual tiene los datos almacenados en un sistema de ficheros, y queremos cambiar a SQL. Para ello sigo el proceso lógico que seguiria al migrar un sistema así, creamos nuestra clase SQL y menciono que para reemplazarlo debemos hacer lo mismo que haciamos en la clase con los ficheros. Aquí me doy cuenta de tu comentarrio ya que si, puede parecer confuso. Heredo temporalmente para explicar que debemos implementar los mismos métodos que teníamos en la otra clase. de hecho menciono que eso esta mal, pero bueno si, puede parecer confuso. Posteriormente en el vídeo creo la intefaz IAlmacenamiento la cual es la que implementan tanto AlmacenamientoFichero como AlmacenamientoSQL, así que son hermanas. La idea principal del vídeo es presentar un caso de uso, mas o menos real, como se haria para resolverlo paso a paso.
No, no no MALLL! el subtipo sustituye al tipo base o sea dios... si B es un subtipo de A entonces B sustituye A. y parece obvio pero no lo es, y de ahi el principio. Fuck !
Pero, ¿por qué no cuentas qué relación hay entre ambos patos? ¿Heredan de una misma clase base? ¿El de juguete hereda del otro? ¿Cuál es el padre y cuál el hijo? Se supone que estás explicando que un padre debe poder sustituir a un hijo. Pues di cuál es cuál.
Blog: www.netmentor.es/Entrada/solid-principio-sustitucion-liskov
twitter: twitter.com/NetMentorTW
Excelente Explicación, felicitaciones. Saludos desde Guatemala.
Que buena lista de SOLID! super claro, gracias!
Muy buen vídeo; como todos los de esta lista de reproducción sobe SOLID.
Buen ejemplo. Gracias
gracias por el apoyo :D
Gran explicación, tengo una duda con relación al principio , Si digamos que tengo una clase Persona y así mismo tengo dos clases más que serían , cliente y proveedor los cuales tendrían los mismo atributos que persona más algunos atributos propios de ellos, En ese caso si mi clase Cliente y Proveedor heredan de Persona, digamos para ahorrarme código, estaría violando el principio? Ya que Proveedor no sería igual a Persona al tener más atributos ,en ese caso como lo solucionaría ? Espero tu respuesta, gracias gran video
Hola buenas, si te he entendido bien, lo que tienes es tu clase persona, la cual es común para ambas clases. Tu caso de heredar de persona esta bien, hasta cierto punto. pero hoy en dia se recomienda mas un patron de composición sobre la herencia utilizando el patron abierto cerrado.
Lo que quiero decir es que Persona, deberia ser un atributo dentro de cada una de las clases. En el único caso donde yo personalmente heredo de clases es cuando tengo una clase base en común para muchas otras clases, en ese caso lo que haria sería una clase abstracta.
Pero si, en tu caso, Persona deberia ser un atributo de cada una de las clases, tanto cliente como proveedor.
Utilizando el principio(no patrón) abierto cerrado *
Oh cierto el principio de Open / Close , aún no me habia quedado claro del todo por lo que veo! Muchas gracias , soy un estudiante de ingeniería y ahora mismo estoy desarrollando un proyecto para mí clase de programacion, entonces me había estado dando vueltas eso por estos días, gracias por pronta respuesta !
Pero has dejado de tener disponible el método para obtener FileInfo (InformacionFichero) no?
A vale que para lo único que lo usas es para saber si el archivo existe.
Yo creo que en este vídeo no usas realmente Liskov. Estás usando polimorfismo, a secas.
son terminos que en la practica representan el mismo Concepto.
No me parece buen ejemplo porque partes de la base de que SQL herede de Fichero. Y eso es un error. Ambas clases deberían ser, conceptualmente, hijas de una misma base, o mejor aún, de un interfaz. En cualquier caso, hermanas. Pero no padre/hija.
no se si has visto el vídeo entero, pero la idea del vídeo es presentar el porqué necesitamos Liskov y luego mostrar el caso de uso.
Por ejemplo, menciono que tenemos una aplicacion X la cual tiene los datos almacenados en un sistema de ficheros, y queremos cambiar a SQL.
Para ello sigo el proceso lógico que seguiria al migrar un sistema así, creamos nuestra clase SQL y menciono que para reemplazarlo debemos hacer lo mismo que haciamos en la clase con los ficheros. Aquí me doy cuenta de tu comentarrio ya que si, puede parecer confuso. Heredo temporalmente para explicar que debemos implementar los mismos métodos que teníamos en la otra clase.
de hecho menciono que eso esta mal, pero bueno si, puede parecer confuso.
Posteriormente en el vídeo creo la intefaz IAlmacenamiento la cual es la que implementan tanto AlmacenamientoFichero como AlmacenamientoSQL, así que son hermanas.
La idea principal del vídeo es presentar un caso de uso, mas o menos real, como se haria para resolverlo paso a paso.
mmm
No, no no MALLL! el subtipo sustituye al tipo base o sea dios... si B es un subtipo de A entonces B sustituye A. y parece obvio pero no lo es, y de ahi el principio. Fuck !
Pero, ¿por qué no cuentas qué relación hay entre ambos patos? ¿Heredan de una misma clase base? ¿El de juguete hereda del otro? ¿Cuál es el padre y cuál el hijo? Se supone que estás explicando que un padre debe poder sustituir a un hijo. Pues di cuál es cuál.
Que pasa si por equivocacion al pato que no es de plastico le quiero cargar pilas por detras? Me ligo un picotazo?