Buenas! Estoy empezando con analisis de POO y tengo un par de dudillas, sed suaves por favor.
¿Respeta liskov el hacer una clase hija con un constructor con mas parametros que el constructor del padre?
¿Respeta liskov hacer metodos en las clases hijas que no tiene la clase padre?
Un saludo!
No entiendo muy bien lo de "respeta" pero sí y sí.
Es decir:
Padre(at1, at2) {
at1 = at1;
at2 = at2;
}
Hijo(at1, at2, at3) {
super(at1, at2);
at3 = at3;
}y al hijo le puedes meter más métodos, peeeeeeeeeeeero, si tú haces:
Padre p = new Hijo(at1, at2, at3);p sólo puede usar los métodos del padre, no los del hijo.
¿Te refieres a eso?
A ver, disculpa que estoy en el curro y no puedo buscarlo bien, pero de wikipedia mismamente
Principio de sustitución de Liskov u LSP es un principio de la programación orientada a objetos. y puede definirse como: Cada clase que hereda de otra puede usarse como su padre sin necesidad de conocer las diferencias entre ellas
Significa que un hijo puede usarse como padre pero no al revés.
Es decir, sí se pueden sustituir pero unilateralmente, sólamente se puede sustituir el padre por el hijo.
Cualquier lenguaje con herencia te va a dejar sustituir por hijos.
Lo que viene a hablar Lisvok es de la funcionalidad y los métodos. Es decir, que las clases hijas no deberían modificar comportamientos de las clases padres para que así puedan sustituirse sin problema (bueno no es así, que las subclases deben respetar siempre el contrato de la clase padre y deberías sospechar cuando una subclase sobreescribe métodos de la clase padre).
Cuando las hijas modifican comportamientos definidos en las clases padres normalmente es por malos diseños (un mal diseño inicial en el que has hecho suposiciones que no han sido correctas) y acabas haciendo una subclase por cada nuevo comportamiento (y más aún cuando éstos son cruzados) y peor aún, éste será impredecible cuando se usen las abstracciones (puedes suponer que vas a hacer algo y luego una de sus subclases no lo hace).
Así que a tu respuesta, las dos es que SÍ y te diré también que este principio se lo pasan por el ojete la mayoría de librerías y frameworks que hay.