Il Principio di sostituzione di Liskov riguarda la protezione degli invarianti di stato?

Question

Il Principio di sostituzione di Liskov riguarda la protezione degli invarianti di stato?

#1 da (10 voti)
#2 da (3 voti)
#3 da (-4 voti)

1

Wiki dice:

Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.).

Comprensione da questo,

Se T è un'astrazione che fornisce l'incapsulamento per proteggere gli invarianti dello stato mantenuti da istanze di T , allora S è un'astrazione che DEVE almeno fornisci l'incapsulamento per proteggere gli stessi invarianti di quegli stati ereditati gestiti da istanze di S .

Qui l'astrazione non può non solo essere una classe ma anche una funzione. Ad esempio: funzione scritta in paradigma prototipo (ES5 JavaScript)

Una classe ( T o S ) sa, i contratti a cui le loro istanze dovrebbero obbedire.

LSP è circa S che garantisce l'incapsulamento per proteggere l'invariante di stato, che viene ereditato da T . La mia comprensione è che correctness riguarda proteggere gli invarianti per mantenere la correttezza di stato.

È questa la giusta comprensione?

object-oriented encapsulation design-patterns liskov-substitution

posta user1787812 18.10.2017 - 16:40

fonte

3 risposte

Leggi altre domande sui tag object-oriented encapsulation design-patterns liskov-substitution

MVVM. È un odore di codice quando il modello di vista ha proprietà con i nomi mostra / nascondi / mostra che appartengono semanticamente alla vista? È comune scrivere parser di file in lingue superiori come Java?

score 10 · Answer 1

No, non la penso così

LSP dice che S può sostituire T. Ciò significa in pratica che S adempie agli stessi obblighi contrattuali che T fa. Lo scrittore di S può esporre lo stato interno (rompendo così l'incapsulamento) senza violazione del contratto API originale.

Stato è un dettaglio dell'implementazione, non un comportamento.

score 3 · Answer 2

Non completamente. Se alcune classi base forniscono una garanzia di immutabilità per il suo stato, anche i suoi sottotipi dovrebbero fornire tale garanzia. Se alcune classi base garantiscono una relazione invariante per il suo stato, allora anche i suoi sottotipi dovrebbero fare questa garanzia. Ma ci sono anche molte più "proprietà desiderabili" di classi (e funzioni) rispetto a come si comporta il loro stato.

Un altro buon modo per vederlo è descritto nel documento originale di Liskov, che questa domanda riassume: i sottotipi non dovrebbero rafforzare le precondizioni o indebolire le postcondizioni.

score -4 · Answer 3

Sì, si tratta di preservare le invarianti, nonché le precondizioni e le postcondizioni. Tuttavia, la sostituzione di Liskov non è un principio, semplicemente qualcosa che devi fare per eseguire l'ingegneria del software usando i contratti.

Una volta completata l'incapsulamento, una classe derivata non può modificare gli invarianti di stato della classe base, anche se l'autore desidera eseguire tale modifica.

La parola "principio" è stata aggiunta nello stesso periodo in cui incomprensioni diffuse del lavoro di Liskov hanno cominciato ad emergere. Se leggi il suo libro originale con Guttag, Abstraction and Specification in Program Development (usando CLU), o le sue opere successive sulla sostituzione di tipo, troverai che si tratta di specifiche di contratto formali e informali. Per qualche ragione, le idee di Liskov furono alla fine interpretate come sull'implementazione delle firme dei metodi in linguaggi come Java che supportano le interfacce. Ovviamente tali linguaggi non hanno contratti, quindi puoi avere molte interpretazioni su quale dovrebbe essere il contratto.