Cita:
Iniciado por yoguuu 
Bueno asi a tontas y a lokas xD (por ke para ser sinceros, no me
Bueno, pero luego no te quejes si no entiendes o no te responden... primero lee los libros, y luego pregunta, no al revés. A mi también me da "modorra" contestar una y otra vez las mismas preguntas de conceptos cuando hay mucho material para leer.
Cita:
Iniciado por yoguuu lo he mirado mucho) creo haber entendido ke el "Principio de Liskov" explica entre otras cosas supongo o con matices... que a medida que vas haciendo herencias y se va prolongando la cosa... es mas facil ke surjan los errores si no se ha echo to de una forma digamos "correcta"... conceptos de especifidad y todo eso todavía son munnncho pa mi xDDD jejeje
A grandes rasgos dice que el famoso "es un" (is_a) que generalmente usan los docentes para enseñarnos "herencia" no es suficiente. No basta con "ser" hay que "comportarse como tal".
Generalmente hago el mismo chiste cuando trato el tema en un curso: "un docente
es una persona, pero no basta, debe comportarse como tal". Otro ejemplo más real: tienes un sistema que liquida sueldos, una clase base "Empleado" y subclases Gerente, Desarrollador, Administrativa y Becario (asumamos que el último no cobra sueldo).
Usas polimorfismo y recibe el método "liquidarSueldo" objetos de tipo Empleado. Bien, cuando en un momento recibes de tu lista de empleados un becario, que debe hacer el sistema?
- ¿Emitir un comprobante impreso pero con valor 0?
- ¿Agregar un "if" preguntando si es becario, y no hacer nada?
- etc
Supongamos que el 1) no es aceptable por el gasto de papel y te piden que no se impriman (no tiene sentido), pasamos al punto 2), agregamos un "if".
¿No estamos "codificando a fuego" nuestro sistema para un comportamiento particular? rompiendo el polimorfismo, justamente,
el patrón estratégico más importante que tiene la POO. Cada vez que tenemos que cambiar nuestro código generamos nuevos costos y nuevos posibles errores.
Por eso cada vez nos cuesta más desarrollar un sistema, hasta que tenemos que tirarlo y desarrollar otro de cero... y empezamos otra vez con los problemas del mal diseño.
Los principios de diseño te dicen que
"desarrolla cerrado al cambio y abierto a la extensión" (Principio Open/Closed, "Abierto / Cerrado"). Por ejemplo, tu código debe ser reutilizable (¿no es la idea de la OO?) y con solo agregar código sin tocar el existente lograrás ir adecuarte a los cambios, a los nuevos requerimientos. No te olvides que nuestro código lo usan muchos otros objetos, si este cambiara, generaría un efecto en cadena, posiblemente, dejando de funcionar lo ya existente y tener que modificar más objetos.
Esta forma de "extensión" es agregar más clases a la herencia y el método "liquidarSueldo" no se modifica, pero si tu no haces correctas herencias, no puedes hacer lo primero, por lo tanto tu sistema se degradará en cascada.
Esta simple tontería el autor demuestra con muchos ejemplos que hacer "herencia por herencia", "por reutilizar código", no es suficiente y genera grandes problemas en los diseños.
Es una de las razones que me ven de mal humor cuando veo que implementan herencia a los golpes, prueba y error, con el argumento solo de "reutilizar código"
