นี่เป็นการละเมิดหลักการทดแทน Liskov หรือไม่?

สมมติว่าเรามีรายการของเอนทิตีงานและProjectTaskประเภทย่อย สามารถปิดงานได้ตลอดเวลายกเว้นงานProjectTasksที่ไม่สามารถปิดได้เมื่อพวกเขามีสถานะเป็นเริ่มต้น UI ควรตรวจสอบให้แน่ใจว่าไม่มีตัวเลือกในการปิดการเริ่มต้นทำงานProjectTaskแต่มีการป้องกันบางอย่างในโดเมน:

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

ตอนนี้เมื่อเรียกClose()ใช้งานมีโอกาสที่การโทรจะล้มเหลวหากเป็นProjectTaskสถานะเริ่มต้นเมื่อไม่เป็นถ้าเป็นภารกิจพื้นฐาน แต่นี่คือข้อกำหนดทางธุรกิจ มันควรจะล้มเหลว สิ่งนี้ถือได้ว่าเป็นการละเมิดหลักการทดแทน Liskovหรือไม่?

ใช่เป็นการละเมิด LSP หลักการทดแทน Liskov ต้องการสิ่งนั้น

• เงื่อนไขเบื้องต้นไม่สามารถเสริมความแข็งแกร่งในประเภทย่อย
• Postconditions ไม่สามารถลดลงได้ในประเภทย่อย
• ค่าคงที่ของซูเปอร์ไทป์จะต้องเก็บรักษาไว้ในประเภทย่อย
• ข้อ จำกัด ประวัติ ("กฎประวัติศาสตร์") วัตถุนั้นได้รับการยกย่องว่าสามารถปรับเปลี่ยนได้ด้วยวิธีการของพวกเขาเท่านั้น (encapsulation) เนื่องจากชนิดย่อยอาจแนะนำวิธีการที่ไม่ปรากฏใน supertype การแนะนำวิธีการเหล่านี้อาจอนุญาตให้มีการเปลี่ยนแปลงสถานะในชนิดย่อยที่ไม่อนุญาตใน supertype ข้อ จำกัด ประวัติห้ามสิ่งนี้

ตัวอย่างของคุณแบ่งข้อกำหนดแรกโดยเสริมสร้างเงื่อนไขก่อนเรียกClose()วิธีการ

คุณสามารถแก้ไขได้โดยนำสภาพที่แข็งแกร่งมาไว้ที่ระดับบนสุดของลำดับชั้นการสืบทอด:

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

โดยกำหนดว่าการเรียกร้องของClose()จะใช้ได้เฉพาะในรัฐเมื่อCanClose()ผลตอบแทนtrueให้คุณสภาพก่อนนำไปใช้Taskเช่นเดียวกับProjectTaskการแก้ไขการละเมิด 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();
    }
}

ใช่. สิ่งนี้ละเมิด LSP

ข้อเสนอแนะของฉันคือการเพิ่มCanCloseเมธอด / คุณสมบัติเข้ากับภารกิจพื้นฐานดังนั้นงานใด ๆ สามารถบอกได้ว่างานในสถานะนี้สามารถปิดได้หรือไม่ นอกจากนี้ยังสามารถให้เหตุผลว่าทำไม Closeและลบเสมือนจาก

ตามความคิดเห็นของฉัน:

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

หลักการการแทนที่ Liskov ระบุว่าคลาสพื้นฐานควรถูกแทนที่ด้วยคลาสย่อยใด ๆ ของเขาโดยไม่เปลี่ยนแปลงคุณสมบัติที่ต้องการของโปรแกรม ตั้งแต่เพียงProjectTaskยกข้อยกเว้นเมื่อปิดโปรแกรมที่จะต้องมีการเปลี่ยนแปลงเพื่อ acommodate การที่ควรจะนำมาใช้แทนProjectTask ดังนั้นจึงเป็นการละเมิดTask

แต่ถ้าคุณแก้ไขการTaskระบุในลายเซ็นของมันว่ามันอาจทำให้เกิดข้อยกเว้นเมื่อปิดแล้วคุณจะไม่ได้ละเมิดหลักการ

การละเมิด LSP ต้องการสามฝ่าย Type T, Subtype S และโปรแกรม P ที่ใช้ T แต่ให้อินสแตนซ์ของ S

คำถามของคุณระบุ T (Task) และ S (ProjectTask) แต่ไม่ใช่ P ดังนั้นคำถามของคุณไม่สมบูรณ์และคำตอบนั้นผ่านการรับรอง: หากมี P ที่ไม่คาดหวังข้อยกเว้นสำหรับ P นั้นคุณมี LSP การละเมิด หาก P ทุกคนคาดว่าจะมีข้อยกเว้นแสดงว่าไม่มีการละเมิด LSP

แต่คุณทำมีSRPละเมิด ความจริงที่ว่าสถานะของงานสามารถเปลี่ยนแปลงได้และนโยบายที่ว่างานบางอย่างในบางรัฐไม่ควรเปลี่ยนเป็นสถานะอื่นเป็นความรับผิดชอบที่แตกต่างกันสองอย่าง

• ความรับผิดชอบ 1: แสดงภารกิจ
• ความรับผิดชอบที่ 2: ใช้นโยบายที่เปลี่ยนแปลงสถานะของงาน

ความรับผิดชอบทั้งสองนี้เปลี่ยนไปด้วยเหตุผลที่แตกต่างกันดังนั้นจึงควรแยกชั้นเรียน งานควรจัดการกับความเป็นจริงของงานและข้อมูลที่เกี่ยวข้องกับงาน TaskStatePolicy ควรจัดการกับวิธีการเปลี่ยนงานจากรัฐสู่รัฐในแอปพลิเคชันที่กำหนด

สิ่งนี้อาจจะใช่หรือไม่ใช่เป็นการละเมิด LSP

อย่างจริงจัง. ได้ยินฉัน

หากคุณปฏิบัติตาม LSP วัตถุประเภทProjectTaskต้องทำงานเป็นวัตถุประเภทTaskที่คาดว่าจะทำงาน

ปัญหาเกี่ยวกับรหัสของคุณคือคุณยังไม่ได้บันทึกว่าวัตถุประเภทTaskใดที่คาดว่าจะทำงาน คุณเขียนโค้ดแล้ว แต่ไม่มีสัญญาใด ๆ Task.Closeฉันจะเพิ่มสัญญาสำหรับ ขึ้นอยู่กับสัญญาที่ฉันเพิ่มรหัสสำหรับProjectTask.Closeทำหรือไม่ปฏิบัติตาม LSP

รับสัญญาต่อไปนี้สำหรับงานปิดรหัสสำหรับProjectTask.Close ไม่เป็นไปตาม 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;
     }

ได้รับสัญญาต่อไปนี้สำหรับ Task.Close รหัสสำหรับการProjectTask.Close ไม่ปฏิบัติตาม 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;
     }

วิธีการที่อาจถูกเขียนทับควรจัดทำเป็นเอกสารด้วยสองวิธี:

• เอกสาร "พฤติกรรม" ที่ลูกค้าสามารถรู้ได้ว่าวัตถุใดเป็นผู้รับTaskแต่ไม่ทราบว่าคลาสเป็นอินสแตนท์โดยตรงของอะไร นอกจากนี้ยังบอกนักออกแบบของคลาสย่อยที่การแทนที่มีความสมเหตุสมผลและไม่เหมาะสม

• เอกสาร "พฤติกรรมเริ่มต้น" สิ่งที่ลูกค้าสามารถพึ่งพาได้ซึ่งรู้ว่าวัตถุผู้รับเป็นตัวอย่างโดยตรงของTask(เช่นสิ่งที่คุณได้รับหากคุณใช้new Task()นอกจากนี้ยังบอกนักออกแบบของคลาสย่อยว่าพฤติกรรมนั้นจะได้รับการสืบทอดหากพวกเขาไม่ แทนที่วิธีการ

ตอนนี้ความสัมพันธ์ต่อไปนี้ควรถือ:

• ถ้า S เป็นประเภทย่อยของ T พฤติกรรมที่เป็นเอกสารของ S ควรปรับแต่งพฤติกรรมที่บันทึกไว้ของ T
• ถ้า S เป็นประเภทย่อยของ (หรือเท่ากับ) T พฤติกรรมของรหัสของ S ควรปรับแต่งพฤติกรรมที่บันทึกไว้ของ T
• ถ้า S เป็นประเภทย่อยของ (หรือเท่ากับ) T พฤติกรรมเริ่มต้นของ S ควรปรับแต่งพฤติกรรมที่บันทึกไว้ของ T
• พฤติกรรมที่แท้จริงของรหัสสำหรับคลาสควรปรับแต่งพฤติกรรมเริ่มต้นของเอกสาร

มันไม่ได้เป็นการละเมิดหลักการทดแทน Liskov

หลักการชดเชย Liskov พูดว่า:

Let Q (x)เป็นทรัพย์สินสามารถพิสูจน์ได้เกี่ยวกับวัตถุxประเภทT ให้Sเป็นชนิดย่อยของT ประเภทSละเมิดหลักการทดแทน Liskov หากวัตถุyของประเภทSมีอยู่เช่นนั้นq (y)ไม่สามารถพิสูจน์ได้

เหตุผลที่ทำไมการดำเนินการตามประเภทย่อยของคุณจึงไม่ได้เป็นการละเมิดหลักการทดแทน Liskov ค่อนข้างง่าย: ไม่มีสิ่งใดที่พิสูจน์ได้เกี่ยวกับสิ่งที่Task::Close()เกิดขึ้นจริง แน่นอนว่าProjectTask::Close()พ่นยกเว้นเมื่อStatus == Status.Startedแต่อาจจะอยู่ในStatus = Status.ClosedTask::Close()

ใช่มันเป็นการละเมิด

ฉันขอแนะนำให้คุณมีลำดับชั้นย้อนหลังของคุณ ถ้าไม่ใช่ทุกคนTaskสามารถปิดclose()ได้แสดงว่าไม่ได้อยู่ในTaskนั้น บางทีคุณอาจต้องการอินเทอร์เฟซCloseableTaskที่ไม่ProjectTasksสามารถนำไปใช้ได้ทั้งหมด

นอกเหนือจากการเป็นปัญหาของ LSP ดูเหมือนว่าใช้ข้อยกเว้นในการควบคุมการไหลของโปรแกรม (ฉันต้องสมมติว่าคุณได้รับการยกเว้นเล็กน้อยนี้ที่อื่นและทำขั้นตอนที่กำหนดเองแทนที่จะปล่อยให้แอปของคุณพัง

ดูเหมือนว่านี่เป็นสถานที่ที่ดีในการใช้รูปแบบสถานะสำหรับ TaskState และให้วัตถุสถานะจัดการการเปลี่ยนที่ถูกต้อง

ฉันหายไปที่นี่เป็นสิ่งสำคัญที่เกี่ยวข้องกับ LSP และการออกแบบโดยสัญญา - ในเงื่อนไขที่จำเป็นมันเป็นผู้โทรที่มีความรับผิดชอบคือการทำให้แน่ใจว่าจะเป็นไปตามเงื่อนไข รหัสที่เรียกว่าในทฤษฎี DbC ไม่ควรตรวจสอบเงื่อนไขเบื้องต้น สัญญาควรระบุว่าเมื่อใดที่งานสามารถปิดได้ (เช่น CanClose ส่งคืนจริง) จากนั้นรหัสการโทรควรตรวจสอบให้แน่ใจว่าเป็นไปตามเงื่อนไขก่อนที่จะเรียกปิด ()

ใช่เป็นการละเมิดที่ชัดเจนของ LSP

บางคนแย้งที่นี่ว่าการทำให้ชัดเจนในคลาสฐานที่คลาสย่อยสามารถโยนข้อยกเว้นจะทำให้สิ่งนี้ยอมรับได้ แต่ฉันไม่คิดว่ามันจะเป็นจริง ไม่ว่าคุณจะเอกสารอะไรในคลาสพื้นฐานหรือระดับนามธรรมที่คุณย้ายรหัสไปสิ่งที่จำเป็นจะยังคงอยู่ในคลาสย่อยเนื่องจากคุณเพิ่มส่วน "ไม่สามารถปิดงานโครงการที่เริ่มต้น" นี่ไม่ใช่สิ่งที่คุณสามารถแก้ไขได้ด้วยวิธีแก้ปัญหาคุณต้องมีรูปแบบที่แตกต่างกันซึ่งไม่ละเมิด LSP (หรือเราจำเป็นต้องคลายข้อ จำกัด "เงื่อนไขที่ไม่สามารถทำให้แน่นหนาลงได้")

คุณสามารถลองรูปแบบการตกแต่งภายในหากคุณต้องการหลีกเลี่ยงการละเมิด LSP ในกรณีนี้ มันอาจใช้งานได้ฉันไม่รู้