Điều gì có thể đi sai nếu nguyên tắc thay thế Liskov bị vi phạm?

Tôi đã theo dõi câu hỏi được đánh giá cao này về khả năng vi phạm nguyên tắc thay thế Liskov. Tôi biết nguyên tắc thay thế Liskov là gì, nhưng trong đầu tôi vẫn chưa rõ ràng là điều gì có thể sai nếu tôi là một nhà phát triển không nghĩ về nguyên tắc này trong khi viết mã hướng đối tượng.

Tôi nghĩ rằng nó được nêu rất rõ trong câu hỏi đó là một trong những lý do được bình chọn rất cao.

Bây giờ khi gọi Đóng () trên Tác vụ, có khả năng cuộc gọi sẽ thất bại nếu đó là ProjectTask với trạng thái bắt đầu, khi đó sẽ không nếu đó là Nhiệm vụ cơ bản.

Hãy tưởng tượng nếu bạn sẽ:

public void ProcessTaskAndClose(Task taskToProcess)
{
    taskToProcess.Execute();
    taskToProcess.DateProcessed = DateTime.Now;
    taskToProcess.Close();
}

Trong phương thức này, đôi khi lệnh gọi .Close () sẽ nổ tung, vì vậy bây giờ dựa trên việc triển khai cụ thể loại dẫn xuất, bạn phải thay đổi cách thức phương thức này hoạt động từ cách phương thức này sẽ được viết nếu tác vụ không có kiểu con có thể trao cho phương pháp này.

Do vi phạm thay thế liskov, mã sử dụng loại của bạn sẽ phải có kiến ​​thức rõ ràng về hoạt động nội bộ của các loại dẫn xuất để đối xử với chúng khác nhau. Mã cặp đôi chặt chẽ này và nói chung làm cho việc triển khai khó sử dụng nhất quán hơn.

Nếu bạn không hoàn thành hợp đồng đã được xác định trong lớp cơ sở, mọi thứ có thể âm thầm thất bại khi bạn nhận được kết quả bị tắt.

LSP ở các bang wikipedia

• Điều kiện tiên quyết không thể được tăng cường trong một kiểu con.
• Postconditions không thể bị suy yếu trong một kiểu con.
• Bất biến của siêu kiểu phải được bảo toàn trong một kiểu con.

Nếu bất kỳ trong số này không giữ, người gọi có thể nhận được một kết quả mà anh ta không mong đợi.

Hãy xem xét một trường hợp kinh điển từ biên niên sử của các câu hỏi phỏng vấn: bạn đã bắt nguồn Circle từ Ellipse. Tại sao? Bởi vì hình tròn là hình elip IS-AN, tất nhiên!

Ngoại trừ ... hình elip có hai chức năng:

Ellipse.set_alpha_radius(d)
Ellipse.set_beta_radius(d)

Rõ ràng, những điều này phải được xác định lại cho Circle, bởi vì Circle có bán kính đồng đều. Bạn có hai khả năng:

1. Sau khi gọi set_alpha_radius hoặc set_beta_radius, cả hai đều được đặt thành cùng một số tiền.
2. Sau khi gọi set_alpha_radius hoặc set_beta_radius, đối tượng không còn là Vòng tròn.

Hầu hết các ngôn ngữ OO không hỗ trợ ngôn ngữ thứ hai và vì một lý do chính đáng: thật đáng ngạc nhiên khi thấy rằng Vòng tròn của bạn không còn là Vòng tròn nữa. Vì vậy, lựa chọn đầu tiên là tốt nhất. Nhưng hãy xem xét các chức năng sau:

some_function(Ellipse byref e)

Hãy tưởng tượng rằng some_feft gọi e.set_alpha_radius. Nhưng vì e thực sự là một Circle, nên đáng ngạc nhiên là bán kính beta của nó cũng được thiết lập.

Và đây là nguyên tắc thay thế: một lớp con phải được thay thế cho một siêu lớp. Nếu không những thứ đáng ngạc nhiên xảy ra.

Theo cách nói của giáo dân:

Mã của bạn sẽ có rất nhiều mệnh đề CASE / switch .

Mỗi một trong các mệnh đề CASE / switch sẽ cần các trường hợp mới được thêm vào theo thời gian, có nghĩa là cơ sở mã không thể mở rộng và có thể duy trì như mong muốn.

LSP cho phép mã hoạt động giống như phần cứng:

Bạn không phải sửa đổi iPod vì bạn đã mua một cặp loa ngoài mới, vì cả loa ngoài cũ và loa mới đều có cùng giao diện, chúng có thể thay thế cho nhau mà iPod không bị mất chức năng mong muốn.

để đưa ra một ví dụ thực tế với UndoManager của java

nó thừa hưởng từ AbstractUndoableEdithợp đồng có xác định rằng nó có 2 trạng thái (hoàn tác và làm lại) và có thể đi giữa chúng với các cuộc gọi đến undo()vàredo()

tuy nhiên UndoManager có nhiều trạng thái hơn và hoạt động như một bộ đệm hoàn tác (mỗi lệnh gọi undohoàn tác một số nhưng không phải tất cả các chỉnh sửa, làm suy yếu hậu điều kiện)

điều này dẫn đến tình huống giả định khi bạn thêm UndoManager vào CompoundEdit trước khi gọi, end()sau đó gọi hoàn tác trên CompoundEdit đó sẽ dẫn đến việc gọi undo()mỗi lần chỉnh sửa khi phần chỉnh sửa của bạn hoàn tác một phần

Tôi tự lăn UndoManagerđể tránh điều đó (có lẽ tôi nên đổi tên nó thành UndoBuffer)

Ví dụ: Bạn đang làm việc với khung UI và bạn tạo điều khiển UI tùy chỉnh của riêng mình bằng cách phân lớp lớp Controlcơ sở. Các Controllớp cơ sở xác định một phương pháp getSubControls()mà nên trả về một tập hợp các điều khiển lồng nhau (nếu có). Nhưng bạn ghi đè phương thức để thực sự trả về một danh sách ngày sinh của tổng thống Hoa Kỳ.

Vì vậy, những gì có thể đi sai với điều này? Rõ ràng là việc hiển thị điều khiển sẽ thất bại, vì bạn không trả về danh sách các điều khiển như mong đợi. Nhiều khả năng UI sẽ bị sập. Bạn đang phá vỡ hợp đồng mà các lớp con của Control dự kiến ​​sẽ tuân thủ.

Bạn cũng có thể nhìn nó từ quan điểm mô hình hóa. Khi bạn nói rằng một thể hiện của lớp Acũng là một thể hiện của lớp, Bbạn ngụ ý rằng "hành vi có thể quan sát được của một thể hiện của lớp Acũng có thể được phân loại là hành vi có thể quan sát được của một thể hiện của lớp B" (Điều này chỉ có thể nếu lớp Bít cụ thể hơn lớp A.)

Vì vậy, vi phạm LSP có nghĩa là có một số mâu thuẫn trong thiết kế của bạn: bạn đang xác định một số danh mục cho các đối tượng của mình và sau đó bạn không tôn trọng chúng trong quá trình thực hiện của mình, điều gì đó phải sai.

Giống như làm một hộp với một thẻ: "Hộp này chỉ chứa các quả bóng màu xanh", và sau đó ném một quả bóng màu đỏ vào nó. Việc sử dụng thẻ như vậy là gì nếu nó hiển thị thông tin sai?

Tôi đã thừa hưởng một cơ sở mã gần đây có một số người vi phạm Liskov chính trong đó. Trong các lớp học quan trọng. Điều này đã gây cho tôi những nỗi đau rất lớn. Hãy để tôi giải thích tại sao.

Tôi có Class A, mà bắt nguồn từ Class B. Class Avà Class Bchia sẻ một loạt các thuộc tính Class Aghi đè với việc thực hiện riêng của nó. Đặt hoặc nhận một thuộc Class Atính có tác dụng khác với cài đặt hoặc nhận chính xác cùng một thuộc tính Class B.

public Class A
{
    public virtual string Name
    {
        get; set;
    }
}

Class B : A
{
    public override string Name
    {
        get
        {
            return TranslateName(base.Name);
        }
        set
        {
            base.Name = value;
            FunctionWithSideEffects();
        }
    }
}

Đặt sang một bên thực tế rằng đây là một cách cực kỳ khủng khiếp để dịch trong .NET, có một số vấn đề khác với mã này.

Trong trường hợp Namenày được sử dụng như một chỉ mục và một biến điều khiển luồng ở một số nơi. Các lớp trên được rải rác khắp codebase ở cả dạng thô và dẫn xuất của chúng. Vi phạm nguyên tắc thay thế Liskov trong trường hợp này có nghĩa là tôi cần biết ngữ cảnh của mỗi lệnh gọi đến từng hàm lấy lớp cơ sở.

Mã này sử dụng các đối tượng của cả hai Class Avà Class Bvì vậy tôi không thể đơn giản tạo ra sự Class Atrừu tượng để buộc mọi người sử dụng Class B.

Có một số chức năng tiện ích rất hữu ích hoạt động Class Avà các chức năng tiện ích rất hữu ích khác hoạt động Class B. Lý tưởng nhất là tôi muốn có thể sử dụng bất kỳ chức năng tiện ích nào có thể hoạt động Class Atrên Class B. Nhiều chức năng Class Bcó thể dễ dàng thực hiện Class Anếu không vi phạm LSP.

Điều tồi tệ nhất ở đây là trường hợp cụ thể này thực sự khó tái cấu trúc vì toàn bộ ứng dụng bản lề trên hai lớp này, hoạt động trên cả hai lớp và sẽ phá vỡ hàng trăm cách nếu tôi thay đổi điều này (mà tôi sẽ làm dù sao).

Những gì tôi sẽ phải làm để khắc phục điều này là tạo một thuộc NameTranslatedtính, đây sẽ là Class Bphiên bản của Nametài sản và rất, rất cẩn thận thay đổi mọi tham chiếu đến thuộc tính dẫn xuất Nameđể sử dụng thuộc NameTranslatedtính mới của tôi . Tuy nhiên, thậm chí một trong những tham chiếu này sai toàn bộ ứng dụng có thể nổ tung.

Cho rằng codebase không có các bài kiểm tra đơn vị xung quanh nó, điều này khá gần với kịch bản nguy hiểm nhất mà nhà phát triển có thể gặp phải. Nếu tôi không thay đổi vi phạm, tôi phải tiêu tốn một lượng lớn năng lượng tinh thần để theo dõi loại đối tượng nào đang được vận hành trong mỗi phương pháp và nếu tôi khắc phục vi phạm, tôi có thể làm cho toàn bộ sản phẩm phát nổ vào thời điểm không phù hợp.

Nếu bạn muốn cảm thấy vấn đề vi phạm LSP, hãy nghĩ điều gì xảy ra nếu bạn chỉ có dll / .jar của lớp cơ sở (không có mã nguồn) và bạn phải xây dựng lớp dẫn xuất mới. Bạn không bao giờ có thể hoàn thành nhiệm vụ này.