Ich verwende eine API, die gegen das Liskov-Substitutionsprinzip verstößt: Sie löst ihren eigenen Exception-Typ aus, der Exception erweitert, aber die Exception-Nachricht von der Basisklasse in ein neues ErrorCode-Feld legt und eine eigene (nutzlose) Nachricht in die Message schreibt Feld. Um die richtige Nachricht anzuzeigen, muss die Ausnahme daher in den DerivedException-Typ umgewandelt und das ErrorCode-Feld verwendet werden. Wenn ich es als Exception-Objekt behandle, bekomme ich die falsche Nachricht.
Jetzt ärgert mich das auf einer stilistischen Ebene, aber es ist einfach genug, um herumzukommen: Ich kann einfach DerivedException fangen und es so verwenden, wie der Programmierer es beabsichtigt hat. Meine Frage ist also: Was ist das Wichtigste am Liskow-Prinzip? Was sind die praktischen Probleme, denen Menschen mit Hierarchien begegnen können, die gegen das Prinzip verstoßen?
Ein praktisches Beispiel:
Wenn Sie eine Protokollierungsklasse mit einer Methode LogException(Exception ex) haben würden, wird die Nachricht, die Sie für unbrauchbar halten, anstelle der "echten" Nachricht protokolliert.
Die Beschreibung der Log-Methode würde sich von "Logs Exception messages" zu "logs Exception messages" ändern, aber manchmal protokolliert nutzlose messages ".
Funktion F will ein Objekt vom Typ T, Sie übergeben es etwas, das behauptet, ein gültiges T zu sein, aber dann verhält es sich anders; dh es gibt Eigenschaften, die für T gelten, auf die sich F stützen kann, aber Ihr Objekt erfüllt sie nicht. Was kann passieren? So ziemlich alles. Fehler, Ausfälle, Abstürze, dein Haus brennt ab.
Tags und Links c# inheritance lsp