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

Giả sử chúng tôi có một danh sách các thực thể Nhiệm vụ và một ProjectTaskloại phụ. Nhiệm vụ có thể được đóng bất cứ lúc nào, ngoại trừ ProjectTaskskhông thể đóng khi chúng có trạng thái Bắt đầu. Giao diện người dùng phải đảm bảo tùy chọn đóng bắt đầu ProjectTaskkhông bao giờ có sẵn, nhưng một số biện pháp bảo vệ có trong miền:

public class Task
{
     public Status Status { get; set; }

     public virtual void Close()
     {
         Status = Status.Closed;
     }
}

public class ProjectTask : Task
{
     public override void Close()
     {
          if (Status == Status.Started) 
              throw new Exception("Cannot close a started Project Task");

          base.Close();
     }
}

Bây giờ khi gọi Close()vào Nhiệm vụ, có khả năng cuộc gọi sẽ thất bại nếu đó là ProjectTasktrạng thái bắt đầu, khi đó sẽ không thực hiện nếu đó là Nhiệm vụ cơ bản. Nhưng đây là yêu cầu kinh doanh. Nó sẽ thất bại. Điều này có thể được coi là vi phạm nguyên tắc thay thế Liskov không?

Có, đó là vi phạm LSP. Nguyên tắc thay thế Liskov yêu cầu rằng

• Đ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.
• Ràng buộc lịch sử ("quy tắc lịch sử"). Các đối tượng được coi là có thể sửa đổi chỉ thông qua các phương thức của chúng (đóng gói). Vì các kiểu con có thể giới thiệu các phương thức không có trong siêu kiểu, nên việc giới thiệu các phương thức này có thể cho phép thay đổi trạng thái trong kiểu con không được phép trong siêu kiểu. Các ràng buộc lịch sử cấm điều này.

Ví dụ của bạn phá vỡ yêu cầu đầu tiên bằng cách củng cố điều kiện tiên quyết để gọi Close()phương thức.

Bạn có thể sửa nó bằng cách đưa điều kiện trước được tăng cường lên cấp cao nhất của hệ thống phân cấp thừa kế:

public class Task {
    public Status Status { get; set; }
    public virtual bool CanClose() {
        return true;
    }
    public virtual void Close() {
        Status = Status.Closed;
    }
}

Bằng cách quy định rằng một cuộc gọi Close()chỉ có hiệu lực ở trạng thái khi CanClose()trả về truebạn thực hiện điều kiện trước áp dụng cho Taskcũng như đối với việc ProjectTasksửa lỗi vi phạm LSP:

public class ProjectTask : Task {
    public override bool CanClose() {
        return Status != Status.Started;
    }
    public override void Close() {
        if (Status == Status.Started) 
            throw new Exception("Cannot close a started Project Task");
        base.Close();
    }
}

Đúng. Điều này vi phạm LSP.

Đề nghị của tôi là thêm CanClosephương thức / thuộc tính vào tác vụ cơ sở, vì vậy bất kỳ tác vụ nào cũng có thể biết liệu tác vụ trong trạng thái này có thể bị đóng hay không. Nó cũng có thể cung cấp lý do tại sao. Và loại bỏ ảo từ Close.

Dựa trên nhận xét của tôi:

public class Task {
    public Status Status { get; private set; }

    public virtual bool CanClose(out String reason) {
        reason = null;
        return true;
    }
    public void Close() {
        String reason;
        if (!CanClose(out reason))
            throw new Exception(reason);

        Status = Status.Closed;
    }
}

public ProjectTask : Task {
    public override bool CanClose(out String reason) {
        if (Status != Status.Started)
        {
            reason = "Cannot close a started Project Task";
            return false;
        }
        return base.CanClose(out reason);
    }
}

Nguyên tắc thay thế Liskov nói rằng một lớp cơ sở nên có thể thay thế bằng bất kỳ lớp con nào của anh ta mà không làm thay đổi bất kỳ thuộc tính mong muốn nào của chương trình. Vì chỉ ProjectTaskđưa ra một ngoại lệ khi đóng cửa, một chương trình sẽ phải được thay đổi thành hàng hóa cho điều đó, nên ProjectTaskđược sử dụng thay thế Task. Vì vậy, nó là một vi phạm.

Nhưng nếu bạn sửa đổi Tasktrong chữ ký của nó rằng nó có thể đưa ra một ngoại lệ khi đóng, thì bạn sẽ không vi phạm nguyên tắc.

Một vi phạm LSP yêu cầu ba 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.

Câu hỏi của bạn đã cung cấp T (Nhiệm vụ) và S (ProjectTask), nhưng không phải P. Vì vậy, câu hỏi của bạn chưa đầy đủ và câu trả lời đủ điều kiện: Nếu tồn tại một P không mong đợi một ngoại lệ thì đối với P đó, bạn có LSP sự vi phạm. Nếu mọi P mong đợi một ngoại lệ thì không có vi phạm LSP.

Tuy nhiên, bạn làm có một SRP vi phạm. Thực tế là trạng thái của một nhiệm vụ có thể được thay đổi, và chính sách rằng một số nhiệm vụ ở một số trạng thái nhất định không nên được thay đổi sang các trạng thái khác, là hai trách nhiệm rất khác nhau.

• Trách nhiệm 1: Thể hiện một nhiệm vụ.
• Trách nhiệm 2: Thực hiện các chính sách thay đổi trạng thái của nhiệm vụ.

Hai trách nhiệm này thay đổi vì những lý do khác nhau và do đó phải ở trong các lớp riêng biệt. Nhiệm vụ nên xử lý thực tế là một nhiệm vụ và dữ liệu liên quan đến một nhiệm vụ. TaskStatePolicy nên xử lý cách chuyển đổi nhiệm vụ từ trạng thái này sang trạng thái khác trong một ứng dụng nhất định.

Điều này có thể hoặc không thể vi phạm LSP.

Nghiêm túc. Hãy nghe tôi nói.

Nếu bạn tuân theo LSP, các đối tượng thuộc loại ProjectTaskphải hành xử như các đối tượng thuộc loại Taskdự kiến ​​sẽ hành xử.

Vấn đề với mã của bạn là bạn chưa ghi lại cách các đối tượng thuộc loại Taskdự kiến ​​sẽ hành xử. Bạn đã viết mã, nhưng không có hợp đồng. Tôi sẽ thêm một hợp đồng cho Task.Close. Tùy thuộc vào hợp đồng tôi thêm, mã cho ProjectTask.Closehoặc không tuân theo LSP.

Đưa ra hợp đồng sau đây cho Nhiệm vụ. Đóng, mã cho ProjectTask.Close không tuân theo LSP:

     // Behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

Đưa ra hợp đồng sau đây cho Nhiệm vụ. Đóng, mã cho ProjectTask.Close không tuân theo LSP:

     // Behaviour: Moves the task to the closed status if possible.
     // If this is not possible, this method throws an Exception
     // and leaves the status unchanged.
     // Default behaviour: Moves the task to the closed state
     // and does not throw any Exception.
     public virtual void Close()
     {
         Status = Status.Closed;
     }

Các phương pháp có thể bị ghi đè phải được ghi lại theo hai cách:

• "Hành vi" ghi lại những gì khách hàng có thể dựa vào, người biết đối tượng người nhận là một Task, nhưng không biết đó là trường hợp trực tiếp của lớp nào. Nó cũng cho các nhà thiết kế của các lớp con ghi đè là hợp lý và không hợp lý.

• "Hành vi mặc định" ghi lại những gì khách hàng có thể dựa vào, người biết rằng đối tượng người nhận là một thể hiện trực tiếp của Task(tức là những gì bạn nhận được nếu bạn sử dụng new Task(). Nó cũng cho người thiết kế các lớp con biết hành vi nào sẽ được kế thừa nếu họ không ghi đè phương thức.

Bây giờ các quan hệ sau đây nên giữ:

• Nếu S là một kiểu con của T, hành vi được ghi lại của S nên tinh chỉnh hành vi được ghi lại của T.
• Nếu S là một kiểu con của (hoặc bằng) T, hành vi của mã S sẽ tinh chỉnh hành vi được ghi lại của T.
• Nếu S là một kiểu con của (hoặc bằng) T, hành vi mặc định của S sẽ tinh chỉnh hành vi được ghi lại của T.
• Hành vi thực tế của mã cho một lớp nên tinh chỉnh hành vi mặc định được ghi lại của nó.

Nó không vi phạm Nguyên tắc thay thế Liskov.

Nguyên tắc thay thế Liskov nói:

Hãy q (x) là một tài sản chứng minh về các đối tượng x kiểu T . Hãy S là một subtype của T . Loại S vi phạm Nguyên tắc thay thế Liskov nếu một đối tượng y loại S tồn tại, do đó q (y) không thể chứng minh được.

Lý do, tại sao việc triển khai tiểu loại của bạn không vi phạm Nguyên tắc thay thế Liskov, khá đơn giản: không có gì có thể được chứng minh về những gì Task::Close()thực sự làm. Chắc chắn, ProjectTask::Close()ném một ngoại lệ khi Status == Status.Started, nhưng vì vậy có thể Status = Status.Closedtrong Task::Close().

Vâng, đó là một vi phạm.

Tôi sẽ đề nghị bạn có thứ bậc của bạn ngược. Nếu không phải tất cả đều Taskcó thể đóng, thì close()không thuộc về Task. Có lẽ bạn muốn có một giao diện CloseableTaskmà tất cả những người không ProjectTasksthể thực hiện được.

Ngoài việc là một vấn đề LSP, có vẻ như nó đang sử dụng các ngoại lệ để kiểm soát luồng chương trình (tôi phải giả sử rằng bạn bắt gặp ngoại lệ tầm thường này ở đâu đó và thực hiện một số luồng tùy chỉnh thay vì để nó làm hỏng ứng dụng của bạn).

Có vẻ như đây là một nơi tốt để triển khai mẫu Trạng thái cho TaskState và để các đối tượng trạng thái quản lý các chuyển đổi hợp lệ.

Tôi đang thiếu ở đây một điều quan trọng liên quan đến LSP và Thiết kế theo Hợp đồng - trong các điều kiện tiên quyết, đó là người gọi có trách nhiệm đảm bảo các điều kiện tiên quyết được đáp ứng. Mã được gọi, theo lý thuyết DbC, không nên xác minh điều kiện tiên quyết. Hợp đồng sẽ chỉ định khi nào một tác vụ có thể được đóng (ví dụ CanClose trả về True) và sau đó mã gọi sẽ đảm bảo điều kiện tiên quyết được đáp ứng, trước khi nó gọi Đóng ().

Có, đó là một vi phạm rõ ràng về LSP.

Một số người tranh luận ở đây rằng việc đưa ra rõ ràng trong lớp cơ sở rằng các lớp con có thể đưa ra ngoại lệ sẽ khiến điều này được chấp nhận, nhưng tôi không nghĩ đó là sự thật. Bất kể bạn viết tài liệu gì trong lớp cơ sở hoặc mức độ trừu tượng mà bạn di chuyển mã đến, các điều kiện tiên quyết vẫn sẽ được tăng cường trong lớp con, bởi vì bạn thêm phần "Không thể đóng Nhiệm vụ dự án bắt đầu" vào nó. Đây không phải là điều bạn có thể giải quyết bằng cách giải quyết, bạn cần một mô hình khác, không vi phạm LSP (hoặc chúng tôi cần nới lỏng các ràng buộc "điều kiện tiên quyết không thể bị hạn chế").

Bạn có thể thử mẫu trang trí nếu bạn muốn tránh vi phạm LSP trong trường hợp này. Nó có thể hoạt động, tôi không biết.