¿Los cambios en el rendimiento infringen el principio de sustitución de Liskov?

14

Di que tengo:

interface Thing
{
    GetThing();
}

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

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

¿Esto es una violación del principio de sustitución de Liskov?

    
pregunta ConditionRacer 10.02.2013 - 00:36

6 respuestas

14

Eso realmente depende. Algunas interfaces tienen, por ejemplo, restricciones de complejidad (obviamente, estas no pueden ejecutarse mediante programación). El caso más básico es "GetThing () da un int - es decir, se detiene", en cuyo caso, la respuesta sería "No": ambas versiones de GetThing () detienen y devuelven un int.

Pero muchas interfaces tienen garantías implícitas o expresamente expresadas de rendimiento, ya sea en complejidad o en tiempo plano. Por ejemplo, en el Estándar de C ++, es ilegal implementar la biblioteca con una llamada de bloqueo, excepto cuando el Estándar lo permita expresamente.

    
respondido por el DeadMG 10.02.2013 - 00:42
8

TL; DR: No

De acuerdo con "Subtipo conductual usando invariantes y restricciones" (la formalización del principio) se ocupa principalmente de las propiedades de "seguridad" de un tipo de objeto. Propiedades que gobiernan la sustituibilidad solo dentro del contexto de información de tipo. Un tipo de objetos es ortogonal a su rendimiento. Por lo tanto, una diferencia en el rendimiento no es una violación del principio de sustitución de Liskov.

    
respondido por el dietbuddha 10.02.2013 - 01:00
6

¿Qué garantías tiene la interfaz? Como GetThing no ofrece garantías, los subtipos no tienen por qué respetarlo.

Si la interfaz fuera algo así como GetThingInLinearTime o si el tipo base es virtual y la implementación predeterminada es una complejidad, entonces la complejidad algorítmica empeora y violaría el LSP.

    
respondido por el Telastyn 10.02.2013 - 03:20
4

El rendimiento del software no tiene nada que ver con el Principio de Sustitución de Liskov.

El principio tiene que ver con la sustitución de subtipos y el impacto en el comportamiento de la sustitución de ese objeto solo en términos de POO.

La entrada y la salida de getThing() siguen siendo las mismas en ambos casos, y es probable que tanto la lentitud como la velocidad pongan los objetos en el mismo estado.

    
respondido por el cgTag 10.02.2013 - 01:04
1

¿Importa lo que el Principio de Sustitución de Liskov dice específicamente? Si un subtipo viola las expectativas del consumidor del supertipo, eso parece ser algo malo, independientemente de que el LSP sea más restrictivo.

En mi opinión, si el subtipo cumple todas las expectativas razonables del consumidor de una abstracción parece ser una buena generalización de la LSP.

Sin embargo, en el ejemplo que ha publicado y con las interfaces de Java en general, no está claro que el consumidor de la interfaz Thing tenga una expectativa razonable de si debería ser rápido o lento. Si los javadocs de la interfaz incluyeran un lenguaje sobre qué operaciones se prometen que serán rápidas, entonces podría haber un argumento para un problema por motivos de rendimiento. Pero la convención de Java es ciertamente para varias implementaciones que tienen diferentes características de rendimiento.

    
respondido por el trptcolin 10.02.2013 - 03:32
-1

El tío Bob respondió una pregunta muy similar en la que afirma que una infracción de LSP requiere 3 partes:

  

El Tipo T, el Subtipo S y el programa P que usa T pero se le da una instancia de S.

Me atrevería a suponer que esta pregunta tiene una estructura similar a la que él respondió, ya que no menciona la P que utiliza la T y qué comportamiento espera P .

Puede encontrar su responder aquí . (Deberá desplazarse hacia abajo y buscar la respuesta del usuario llamado Robert Martin)

    
respondido por el TMc 06.09.2013 - 08:21

Lea otras preguntas en las etiquetas