POO

Comments

  1. ¿Cómo puedo saber en la práctica si una subclase realmente cumple con el Principio de Sustitución de Liskov y no está rompiendo el comportamiento esperado de la clase base?

  2. Si una clase hija necesita restringir el comportamiento de la clase padre (por ejemplo, deshabilitar un método), ¿cómo se debería rediseñar la jerarquía para seguir cumpliendo el principio?

  3. En el ámbito empresarial ¿En que tipo de situación o circunstancia se debe usar él principio de sustitución? Que la clase hija sustituya la clase padre

  4. Que problema puede surgir si una subclase no cumple completamente con el contrato de su clase base según el principio de sustitución de Liskov?

  5. ¿Qué establece el Principio de Sustitución de Liskov respecto al comportamiento de una clase hija en relación con su clase padre dentro del diseño orientado a objetos?

  6. Según el principio, ¿qué deberíamos cuestionarnos cuando una subclase no puede reemplazar a su clase base sin alterar la funcionalidad?

  7. Qué sucede cuando una subclase viola el contrato del comportamiento de la clase padre según el principio de sustitución de Liskov (LSP)?

  8. ¿Cuál es la consecuencia principal de que una subclase rompa el contrato de comportamiento de su clase base, y qué principio de SOLID busca prevenir esto?

  9. ¿No es cierto que al evolucionar una API y modificar el comportamiento de clases existentes, estamos violando el LSP para todos los sistemas que dependían del contrato original?

Post a Comment