Nguyên tắc thay thế của Liskov: Nếu tiểu loại có một số hành vi bổ sung được thực hiện, không có trong loại, thì đây có phải là vi phạm LSP không?

Trong hành trình viết mã tốt hơn, sạch hơn, tôi đang tìm hiểu về các nguyên tắc RẮN. Trong đó, LSP đang tỏ ra hơi khó nắm bắt đúng cách.

Sự nghi ngờ của tôi là điều gì xảy ra nếu tôi có một số phương thức bổ sung trong tiểu loại của tôi, S, không có trong loại, T, liệu điều này có luôn vi phạm LSP không? Nếu có, làm thế nào để extendtôi lớp học của tôi?

Ví dụ: giả sử chúng ta có một Birdloại. Và các kiểu con của nó là Eaglevà Humming Bird. Bây giờ cả hai kiểu con có một số hành vi phổ biến là Bird. Nhưng Eaglecũng có hành vi săn mồi tốt (không có trong Birdloại chung ), mà tôi muốn sử dụng . Do đó, bây giờ tôi sẽ không thể làm điều này:

Bird bird = new Eagle();

Vì vậy, việc đưa ra Eaglenhững hành vi bổ sung phá vỡ LSP?

Nếu có, điều đó có nghĩa là tôi không thể mở rộng các lớp học vì điều đó sẽ gây ra vi phạm LSP?

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

Mở rộng các lớp nên được cho phép theo nguyên tắc Mở / Đóng phải không?

Cảm ơn bạn đã trả lời trước! Như bạn có thể thấy rõ, LSP khiến tôi bối rối như mọi thứ.

Chỉnh sửa: Tham khảo câu trả lời SO này. Trong trường hợp này một lần nữa, khi Carcó hành vi bổ sung như thế ChangeGear, nó vi phạm LSP. Vậy, làm thế nào để chúng tôi mở rộng một lớp học mà không vi phạm LSP?

Sự nghi ngờ của tôi là điều gì xảy ra nếu tôi có một số phương thức bổ sung trong tiểu loại của tôi, S, không có trong loại, T, liệu điều này có luôn vi phạm LSP không?

Câu trả lời rất đơn giản: không.

Điểm quan trọng đối với LSP là Snên thay thế cho T. Vì vậy, nếu Tthực hiện một deletechức năng, Scũng nên thực hiện nó và nên thực hiện xóa khi được gọi. Tuy nhiên, Smiễn phí để thêm chức năng bổ sung hơn và những gì Tcung cấp. Người tiêu dùng của a T, khi được cung cấp Ssẽ không biết về chức năng bổ sung này, nhưng nó được phép tồn tại cho người tiêu dùng Strực tiếp sử dụng.

Rất nhiều ví dụ về cách nguyên tắc có thể bị vi phạm có thể là:

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;
    }
}

Câu trả lời phức tạp hơn một chút: không, miễn là bạn không bắt đầu ảnh hưởng đến trạng thái hoặc hành vi dự kiến ​​khác của loại cơ sở.

Ví dụ: những điều sau đây sẽ là vi phạm:

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);
}

Các loại Point2D, là bất biến; trạng thái của nó không thể thay đổi. Với MyPoint2D, tôi đã cố tình lách hành vi đó để biến nó thành đột biến. Điều đó phá vỡ các ràng buộc lịch sử Point2Dvà do đó là vi phạm LSP.

Dĩ nhiên là không. Nếu đối tượng Eagle có thể được sử dụng bởi bất kỳ mã nào mong đợi Bird hoặc lớp con và hành xử như một Bird sẽ hành xử, bạn vẫn ổn.

Tất nhiên hành vi Eagle chỉ có thể được sử dụng bởi mã nhận thức được rằng đó là một đối tượng như vậy. Chúng tôi hy vọng rằng một số mã sẽ rõ ràng tạo ra một đối tượng Eagle và sử dụng nó như một đối tượng Eagle, trong khi có thể sử dụng bất kỳ mã nào mong đợi các đối tượng Bird.