I cambiamenti nelle prestazioni violano il principio di sostituzione di Liskov?

Dì che ho:

interface Thing
{
    GetThing();
}

class FastThing : Thing 
{
    public int GetThing()
    {
        return 1;
    }
}

class SlowThing : Thing
{
    public int GetThing()
    {
        return GetThingFromDatabase();
    }
}

È una violazione del principio di sostituzione di Liskov?

Dipende davvero. Alcune interfacce hanno, ad esempio, vincoli di complessità (questi ovviamente non possono essere applicati a livello di programmazione). Il caso più semplice è "GetThing () dà un int- cioè si ferma", nel qual caso la risposta sarebbe "No" - entrambe le versioni di GetThing () si fermano e restituiscono un int.

Ma molte interfacce hanno implicito o esplicitamente dichiarato garanzie prestazionali, sia in termini di complessità che di tempo piatto. Ad esempio, nello standard C ++, è illegale implementare la libreria con una chiamata di blocco, tranne nei casi in cui lo standard lo consenta espressamente.

TL; DR: No

Secondo il "Sottotipo comportamentale usando invarianti e vincoli" (la formalizzazione del principio) si occupa principalmente delle proprietà di "sicurezza" di un tipo di oggetti. Proprietà che regolano la sostituibilità solo nel contesto delle informazioni sul tipo. Un tipo di oggetto è ortogonale alla sua prestazione. Pertanto, una differenza nelle prestazioni non costituisce una violazione del principio di sostituzione di Liskov.

Quali garanzie offre l'interfaccia? Poiché GetThingnon fornisce garanzie, i sottotipi non devono rispettarlo.

Se l'interfaccia era qualcosa come GetThingInLinearTimeo se il tipo di base è virtuale e l'implementazione di default è una complessità, poi facendo che la complessità algoritmica peggio sarebbe violare LSP.

Le prestazioni del software non hanno nulla a che fare con il principio di sostituzione di Liskov.

Il principio ha a che fare con la sostituzione dei sottotipi e l'impatto comportamentale della sostituzione di tale oggetto solo in termini di OOP.

L'input e l'output di getThing()rimangono gli stessi per entrambi i casi e sia lentamente che velocemente mettono gli oggetti nello stesso stato.

Importa ciò che il Principio di sostituzione di Liskov stesso afferma specificamente? Se un sottotipo viola le aspettative del consumatore del supertipo, sembra una cosa negativa indipendentemente dal fatto che LSP sia più restrittivo.

Quindi, a mio avviso, se tutte le aspettative ragionevoli del consumatore di un'astrazione siano soddisfatte dal sottotipo sembra essere una buona generalizzazione di LSP.

Tuttavia, nell'esempio che hai pubblicato e con le interfacce Java in generale, non è chiaro che il consumatore Thingdell'interfaccia abbia delle ragionevoli aspettative se debba essere veloce o lento. Se i javadocs dell'interfaccia includessero un linguaggio su quali operazioni promettono di essere veloci, allora potrebbe esserci un argomento per un problema per motivi di prestazioni. Ma la convenzione Java prevede certamente che varie implementazioni abbiano caratteristiche prestazionali diverse.

Lo zio Bob ha risposto a una domanda molto simile in cui afferma che una violazione di LSP richiede 3 parti:

Il tipo T, il sottotipo S e il programma P che utilizza T ma riceve un'istanza di S.

Immagino che questa domanda abbia una struttura simile a quella a cui ha risposto, in quanto non menziona la P che sta usando la T e quale comportamento si aspetta la P.

Puoi trovare la sua risposta qui . (Dovrai scorrere alcuni verso il basso e cercare la risposta dell'utente di nome Robert Martin)