Il principio di sostituzione di Liskov si applica anche alle classi che implementano un'interfaccia?

LSP afferma che le classi dovrebbero essere sostituibili per le loro classi di base, il che significa che le classi derivate e di base dovrebbero essere semanticamente equivalenti.

Ma LSP si applica anche alle classi che implementano un'interfaccia? In altre parole, se un metodo di interfaccia implementato da una classe è semanticamente diverso da ciò che l'utente si aspetta che sia, questo sarebbe considerato una violazione di LSP?

design-patterns design-principles liskov-substitution

— user1483278
fonte

Sì. Esattamente le stesse ragioni e i risultati della violazione di LSP se si tratta di un'interfaccia, una classe astratta, una classe completa, non importa. LSP riguarda l'impostazione e il rispetto delle aspettative per consentire ai consumatori di trattare i tuoi tipi in modo generale.

— Jimmy Hoffa,

Nel complesso (conosco le differenze, ma sto generalizzando qui), le interfacce sono in qualche modo analoghe alle classi astratte pure (termine C ++) e quindi Liskov dovrebbe applicarsi alle interfacce e alle classi che le implementano.

— Jesse C. Slicer,

NB la formulazione dell'LSP con cui ho familiarità parla di sottotipi piuttosto che di classi derivate e di base. Con buona ragione, presumo, perché nessuno dei motivi è specifico dell'eredità e si applica altrettanto bene per qualsiasi altro tipo di sottotipo.

se un metodo di interfaccia implementato da una classe è semanticamente diverso da ciò che l'utente si aspetta che sia, sarebbe considerato una violazione di LSP?

Se l'implementazione è semanticamente diversa dal comportamento documentato attraverso gli invarianti dell'interfaccia e le condizioni pre e post dei suoi metodi, allora la risposta è "sì", sarebbe una violazione dell'LSP. Il principio stabilisce le regole per l'astrazione e le sue implementazioni, senza richiedere che il lato di astrazione sia presente sotto forma di una classe.

Tuttavia, se parliamo di ciò che gli utenti si aspettano , la risposta sarebbe "non necessariamente": gli utenti hanno il diritto di avere aspettative sbagliate.

— dasblinkenlight
fonte

"Se l'implementazione è semanticamente diversa dal comportamento documentato attraverso gli invarianti dell'interfaccia" Potresti approfondire cosa intendi con "invarianti dell'interfaccia"?

— user1483278

@ user1483278 Ecco un articolo sul tipo di invarianti . L'articolo li chiama "invarianti di classe", ma la descrizione si applica anche alle interfacce. Gli invarianti sono condizioni stabilite durante la costruzione e mantenute per tutta la durata di un'istanza. Ad esempio, se un'interfaccia ha una proprietà Nameche non può essere impostata su null, obj.Name != nullsi dice che sia invariante di tale interfaccia.

— dasblinkenlight,

In genere, quando si discute di invarianti, è possibile scrivere un pezzo di codice per verificare che l'invariante sia sostenuto per l'intera durata dell'oggetto. Tuttavia, in genere è più semplice descrivere verbalmente l'invariante in un inglese semplice.

— rwong,