Principio de sustitución de Liskov: si el subtipo tiene algún comportamiento adicional implementado, que no está presente en el tipo, ¿se trata de una violación del LSP?

En mi búsqueda por escribir un código mejor y más limpio, estoy aprendiendo acerca de los principios SOLID. En esto, LSP está demostrando ser poco difícil de entender adecuadamente.

Mi duda es ¿qué pasa si tengo algunos métodos adicionales en mi subtipo, S, que no estaban allí en tipo, T, esto siempre será una violación de LSP? En caso afirmativo, ¿cómo hago extendmis clases?

Por ejemplo, digamos que tenemos un Birdtipo. Y sus subtipos son Eagley Humming Bird. Ahora ambos subtipos tienen un comportamiento común como el Bird. Pero Eagletambién tiene un buen comportamiento depredador (que no está presente en el Birdtipo general ), que quiero usar . Por lo tanto, ahora no podré hacer esto:

Bird bird = new Eagle();

Entonces, ¿dar Eagleese comportamiento extra está rompiendo el LSP?

En caso afirmativo, ¿eso significa que no puedo extender mis clases porque eso causaría una violación de LSP?

class Eagle extends Bird {
   //we are extending Bird since Eagle has some extra behavior also
}

La extensión de clases debe permitirse de acuerdo con el principio de Abierto / Cerrado ¿verdad?

Gracias de antemano por responder! Como puede ver claramente, LSP me tiene confundido como cualquier cosa.

Editar: consulte esta respuesta SO. En esto nuevamente, cuando Cartiene un comportamiento adicional como ChangeGear, viola el LSP. Entonces, ¿cómo ampliamos una clase, sin violar el LSP?

Mi duda es ¿qué pasa si tengo algunos métodos adicionales en mi subtipo, S, que no estaban allí en tipo, T, esto siempre será una violación de LSP?

Respuesta muy simple: no.

El punto para el LSP es que Sdebe ser sustituible por T. Entonces, si Timplementa una deletefunción, también Sdebería implementarla y debería realizar una eliminación cuando se le llame. Sin embargo, Ses libre de agregar funcionalidades adicionales además de lo que Tofrece. Los consumidores de a T, cuando reciben una S, desconocen esta funcionalidad adicional, pero se permite que los consumidores la Sutilicen directamente.

Algunos ejemplos de cómo se puede violar el principio pueden ser:

class T
{
    bool delete(Item x)
    {
        if (item exists)
        {
            delete it
            return true;
        }
        return false;
    }
}

class S extends T
{
    bool delete(Item x)
    {
        if (item doesn't exist)
        {
            add it
            return false;
        }
        return true;
    }
}

Respuesta un poco más compleja: no, siempre y cuando no comience a afectar el estado u otro comportamiento esperado del tipo base.

Por ejemplo, lo siguiente sería una violación:

class Point2D
{
    private readonly double _x;
    private readonly double _y;

    public virtual double X => _x;
    public virtual double Y => _y;

    public Point2D(double x, double y) => (_x, _y) = (x, y);
}

class MyPoint2D : Point2D
{
    private double _x;
    private double _y;

    public override double X => _x;
    public override double Y => _y;

    public MyPoint2D(double x, double y) : 
        base(x, y) => (_x, _y) = (x, y);

    public void Update(double x, double y) => (_x, _y) = (x, y);
}

El tipo Point2D,, es inmutable; su estado no puede ser cambiado. Con MyPoint2D, he eludido deliberadamente ese comportamiento para hacerlo mutable. Eso rompe la restricción del historial Point2Dy, por lo tanto, es una violación del LSP.

Por supuesto no. Si el objeto Eagle puede ser utilizado por cualquier código que espera un Bird o una subclase, y se comporta como un Bird debería comportarse, está bien.

Por supuesto, el comportamiento de Eagle solo puede ser usado por código que es consciente de que es un objeto de este tipo. Es de esperar que algún código cree explícitamente un objeto Eagle y lo use como un objeto Eagle, al tiempo que puede usar cualquier código que espere objetos Bird.