การเปลี่ยนแปลงในการปฏิบัติงานละเมิดหลักการการทดแทน Liskov หรือไม่?

พูดว่าฉันมี:

interface Thing
{
    GetThing();
}

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

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

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

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

แต่อินเทอร์เฟซจำนวนมากมีการรับประกันประสิทธิภาพโดยนัยหรือโดยระบุอย่างชัดเจนไม่ว่าจะในความซับซ้อนหรือในเวลาที่แบน ตัวอย่างเช่นใน C ++ Standard เป็นสิ่งผิดกฎหมายในการใช้งานไลบรารีด้วยการเรียกการบล็อกยกเว้นที่ Standard อนุญาตอย่างชัดแจ้ง

TL; DR: ไม่

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

อินเทอร์เฟซทำอะไรรับประกัน ตั้งแต่GetThingทำให้ไม่มีการรับประกันแล้วชนิดย่อยไม่จำเป็นต้องเคารพมัน

ถ้าอินเตอร์เฟซที่เป็นสิ่งที่ต้องการGetThingInLinearTimeหรือถ้าพิมพ์ฐานเป็นเสมือนและการดำเนินการเริ่มต้นเป็นหนึ่งในความซับซ้อนนั้นการทำที่ซับซ้อนอัลกอริทึมที่เลวร้ายยิ่งจะละเมิด LSP

ประสิทธิภาพของซอฟต์แวร์ไม่เกี่ยวข้องกับหลักการทดแทน Liskov

หลักการเกี่ยวข้องกับการทดแทนชนิดย่อยและผลกระทบเชิงพฤติกรรมของการทดแทนวัตถุนั้นในเงื่อนไข OOP เท่านั้น

อินพุทและเอาท์พุทของgetThing()ยังคงเหมือนเดิมสำหรับทั้งสองกรณีและทั้งช้าและเร็วน่าจะทำให้วัตถุอยู่ในสถานะเดียวกัน

มันมีความสำคัญต่อสิ่งที่หลักการทดแทนของ Liskov พูดอย่างเจาะจงหรือไม่? หากประเภทย่อยละเมิดความคาดหวังของผู้บริโภคของประเภทซุปเปอร์ที่ดูเหมือนว่าสิ่งที่ไม่ดีโดยไม่คำนึงว่า LSP มีข้อ จำกัด มากขึ้น

ดังนั้นในมุมมองของฉันว่าความคาดหวังที่สมเหตุสมผลของผู้บริโภคเกี่ยวกับสิ่งที่เป็นนามธรรมนั้นเป็นจริงหรือไม่โดยกลุ่มย่อยดูเหมือนจะเป็นลักษณะทั่วไปที่ดีของ LSP

อย่างไรก็ตามในตัวอย่างที่คุณโพสต์และด้วยอินเทอร์เฟซ Java โดยทั่วไปไม่ชัดเจนว่าผู้ใช้Thingอินเทอร์เฟซนั้นมีความคาดหวังที่สมเหตุสมผลว่าควรจะเร็วหรือช้า หาก javadocs ของอินเทอร์เฟซต้องรวมภาษาเกี่ยวกับสิ่งที่สัญญาว่าจะดำเนินการอย่างรวดเร็วนั้นอาจมีข้อโต้แย้งสำหรับปัญหาในพื้นที่ประสิทธิภาพ แต่การประชุมแบบจาวานั้นแน่นอนว่าสำหรับการใช้งานที่หลากหลายจะมีคุณสมบัติด้านประสิทธิภาพที่แตกต่างกัน

ลุงบ๊อบตอบคำถามที่คล้ายกันมากซึ่งเขากล่าวว่าการละเมิด LSP ต้องการ 3 ฝ่าย:

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

ฉันเดาว่าคำถามนี้มีโครงสร้างคล้ายกันกับที่เขาตอบกลับโดยที่ไม่ได้พูดถึงPที่ใช้Tและพฤติกรรมที่Pคาดหวัง

คุณสามารถค้นหาของเขาคำตอบที่นี่ (คุณจะต้องเลื่อนลงมาและหาคำตอบจากผู้ใช้ชื่อ Robert Martin)