La jerarquía viola a Liskov, ¿y qué?

Question

Estoy usando una API que viola el principio de sustitución de Liskov: arroja su propio tipo de Excepción que amplía Excepción, pero coloca el mensaje de excepción de la clase base en un nuevo campo ErrorCode y coloca su propio mensaje (inútil) en el campo Mensaje . Por lo tanto, para mostrar el mensaje correcto, necesito convertir la Excepción al tipo DerivedException y usar el campo ErrorCode. Si lo trato como un objeto de excepción, recibo el mensaje equivocado.

Ahora, esto me irrita en un nivel estilístico, pero es bastante fácil de recorrer: simplemente puedo detectar DerivedException y utilizarlo como el programador pretendía. Entonces mi pregunta es esta: ¿cuál es el problema con el principio de Liskov? ¿Cuáles son los problemas prácticos con los que las personas se pueden encontrar al usar jerarquías que violan el principio?

Answer 1

Un ejemplo práctico:

Si desea tener una clase con un método de tala LogException(Exception ex) se registrará el mensaje usted considera inútil, en lugar del mensaje "real".

La descripción del método de registro cambiaría de "registros de mensajes de excepción" a "registros de mensajes de excepción, pero a veces registra mensajes inútiles".

Answer 2

Función F quiere un objeto de tipo T, le pasa algo que dice ser una T válida, pero luego se comporta de manera diferente; es decir, hay propiedades que se mantienen para T, en las que F puede confiar, pero su objeto no las satisface. ¿Que puede pasar? Casi cualquier cosa Errores, fallas, bloqueos, su casa se está incendiando.