Những thay đổi trong hiệu suất có vi phạm Nguyên tắc thay thế Liskov không?

Nói rằng tôi có:

interface Thing
{
    GetThing();
}

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

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

Đây có phải là vi phạm Nguyên tắc thay thế Liskov không?

Điều đó thực sự phụ thuộc. Ví dụ, một số giao diện có các ràng buộc phức tạp (những giao diện này rõ ràng không thể được thi hành theo chương trình). Trường hợp cơ bản nhất là "GetThing () cung cấp cho int- tức là nó dừng lại", trong trường hợp đó, câu trả lời sẽ là "Không" - cả hai phiên bản của GetThing () đều dừng lại và trả về một int.

Nhưng nhiều giao diện đã ngụ ý hoặc tuyên bố rõ ràng đảm bảo hiệu suất, trong sự phức tạp hoặc trong thời gian phẳng. Ví dụ: trong Tiêu chuẩn C ++, việc triển khai thư viện với lệnh gọi chặn ngoại trừ trường hợp Tiêu chuẩn cho phép rõ ràng là bất hợp pháp.

TL; DR: Không

Theo "Phân loại hành vi sử dụng bất biến và ràng buộc" (chính thức hóa nguyên tắc), nó chủ yếu liên quan đến các thuộc tính "an toàn" của một loại đối tượng. Các thuộc tính chi phối sự thay thế chỉ trong bối cảnh thông tin loại. Một loại đối tượng là trực giao với hiệu suất của nó. Do đó, một sự khác biệt trong hiệu suất không phải là vi phạm Nguyên tắc thay thế Liskov.

Giao diện đảm bảo những gì? Vì GetThingkhông đảm bảo nên các kiểu con không cần phải tôn trọng nó.

Nếu giao diện giống như GetThingInLinearTimehoặc nếu loại cơ sở là ảo và việc triển khai mặc định là một độ phức tạp, thì làm cho độ phức tạp thuật toán đó tệ hơn sẽ vi phạm LSP.

Hiệu suất của phần mềm không liên quan gì đến Nguyên tắc thay thế Liskov.

Nguyên tắc phải làm với việc thay thế các kiểu con và tác động hành vi của việc thay thế đối tượng đó chỉ bằng thuật ngữ OOP.

Đầu vào và đầu ra getThing()vẫn giữ nguyên cho cả hai trường hợp và cả chậm và nhanh đều có thể đưa các đối tượng vào cùng một trạng thái.

Có vấn đề gì với nguyên tắc thay thế Liskov nói cụ thể không? Nếu một kiểu con vi phạm sự mong đợi của người tiêu dùng của siêu kiểu, điều đó có vẻ như là một điều xấu bất kể LSP có hạn chế hơn hay không.

Vì vậy, theo quan điểm của tôi, liệu tất cả các kỳ vọng hợp lý của người tiêu dùng về sự trừu tượng có được đáp ứng bởi tiểu loại dường như là một khái quát tốt về LSP.

Tuy nhiên, trong ví dụ bạn đã đăng và với các giao diện Java nói chung, không rõ người tiêu dùng Thinggiao diện có bất kỳ kỳ vọng hợp lý nào về việc nó nên nhanh hay chậm. Nếu javadocs của giao diện bao gồm ngôn ngữ về các hoạt động được hứa hẹn là nhanh, thì có thể có một đối số cho một vấn đề trên cơ sở hiệu suất. Nhưng quy ước Java chắc chắn là cho các triển khai khác nhau có các đặc tính hiệu năng khác nhau.

Chú Bob đã trả lời một câu hỏi tương tự trong đó ông nói rằng vi phạm LSP cần có 3 bên:

Loại T, Subtype S và chương trình P sử dụng T nhưng được cung cấp một thể hiện của S.

Tôi sẽ mạo hiểm đoán rằng câu hỏi này có cấu trúc tương tự như câu hỏi mà anh ta đã trả lời, trong đó nó không đề cập đến P đang sử dụng T và hành vi mà P mong đợi.

Bạn có thể tìm thấy câu trả lời của anh ấy ở đây . (Bạn sẽ cần cuộn xuống một số và tìm câu trả lời từ người dùng có tên Robert Martin)