Nguyên tắc thay thế Liskov cũng áp dụng cho các lớp thực hiện giao diện?

LSP tuyên bố rằng các lớp nên thay thế cho các lớp cơ sở của chúng, có nghĩa là các lớp dẫn xuất và lớp cơ sở phải tương đương về mặt ngữ nghĩa.

Nhưng LSP cũng áp dụng cho các lớp thực hiện giao diện? Nói cách khác, nếu một phương thức giao diện được thực hiện bởi một lớp khác về mặt ngữ nghĩa so với những gì người dùng mong đợi, liệu điều này có bị coi là vi phạm LSP không?

design-patterns design-principles liskov-substitution

— người dùng1483278
nguồn

Đúng. Chính xác những lý do và kết quả là vi phạm LSP nếu đó là một giao diện, một lớp trừu tượng, một lớp đầy đủ, không thành vấn đề. LSP là về việc thiết lập và đáp ứng mong đợi để cho phép người tiêu dùng đối xử với các loại của bạn một cách chung chung.

— Jimmy Hoffa

Nhìn chung (tôi biết sự khác biệt, nhưng tôi đang khái quát ở đây), các giao diện có phần giống với các lớp trừu tượng thuần túy (thuật ngữ C ++) và do đó Liskov nên áp dụng cho các giao diện và các lớp thực hiện chúng.

— Jesse C. Choper

Lưu ý về công thức của LSP mà tôi quen thuộc khi nói về các kiểu con hơn là các lớp cơ sở và dẫn xuất. Với lý do chính đáng, tôi giả sử, bởi vì không có lý do nào là cụ thể đối với thừa kế và cũng áp dụng tốt cho bất kỳ loại phân nhóm nào khác.

nếu một phương thức giao diện được thực hiện bởi một lớp khác về mặt ngữ nghĩa so với những gì người dùng mong đợi, thì điều này có bị coi là vi phạm LSP không?

Nếu việc triển khai khác về mặt ngữ nghĩa với hành vi được ghi nhận qua các bất biến của giao diện và các điều kiện trước và sau của phương thức, thì câu trả lời là "có", đó sẽ là vi phạm LSP. Nguyên tắc thiết lập các quy tắc cho sự trừu tượng hóa và việc thực hiện nó, mà không yêu cầu phía trừu tượng phải có mặt dưới dạng một lớp.

Tuy nhiên, nếu chúng ta nói về những gì người dùng mong đợi , câu trả lời sẽ là "không nhất thiết": người dùng có quyền có những kỳ vọng sai.

— ánh sáng mặt trời
nguồn

"Nếu việc triển khai khác về mặt ngữ nghĩa với hành vi được ghi lại qua các bất biến của giao diện" Bạn có thể giải thích ý của bạn về "bất biến của giao diện" không?

— user1483278

@ user1483278 Đây là một bài viết về loại bất biến . Bài báo gọi chúng là "Bất biến lớp", nhưng mô tả cũng áp dụng cho các giao diện. Bất biến là các điều kiện được thiết lập khi xây dựng và được duy trì trong suốt vòng đời của một thể hiện. Ví dụ: nếu một giao diện có thuộc tính Namekhông thể được đặt thành null, thì obj.Name != nullđược gọi là bất biến của giao diện đó.

— dasblinkenlight

Thông thường khi các bất biến được thảo luận, có thể viết một đoạn mã để xác minh rằng bất biến được duy trì trong toàn bộ thời gian tồn tại của đối tượng. Tuy nhiên, thông thường đơn giản hơn để mô tả bằng lời nói bất biến bằng tiếng Anh.

— rwong