Liskov Substitution Principle

👑 หัวใจหลักของ Liskov Substitution Principle (LSP)

Let Φ(x) be a property provable about objects x of type T. Then Φ(y)_should be true for objects _y of type S where S is a subtype of T.

นี่มันสูตรสมการอะไรกันฟร๊าเนี่ย (เป็นนิยามของคนเสนอเรื่องนี้จริงๆในปี 1998 เลยนะจากแม่ใหญ่ Barbara Liskov) มันเลยมีนิยามอีกตัวที่ทำให้เข้าใจง่ายขึ้นออกมาว่า

Subtypes must be substitutable for their base types.

"คลาสลูกทุกตัวจะต้องสามารถทำหน้าที่แทนคลาสแม่ได้" แปลออกมาแล้วก็มึนๆเหมือนเดิม เดี๋ยวไปดูตัวอย่างให้เข้าใจก่อนว่ามันเป็นยังไง

😵 ตัวอย่างคลาสลูกที่ไม่สามารถแทนคลาสแม่ได้

สมมุติว่าเราต้องจัดการกับของที่เป็น สี่เหลี่ยมผืนผ้า ซักตัว เราก็เลยเขียนคลาส Rectangle ขึ้นมาโดยเก็บ ความกว้าง กับ ความสูง และ สามารถคำนวณพื้นที่ได้ด้วย ตามโค้ดด้านล่างนี้

public class Rectangle
{
    public double Width { get; set; }
    public double Height { get; set; }

    public double GetArea()
    {
        return Width * Height;
    }
}

อยู่มาวันนึง เราต้องการทำงานกับของที่เป็น สี่เหลี่ยมจัตุรัส บ้างล่ะ เราจะทำยังไง ? ถ้ามองแบบเผินๆ สี่เหลี่ยมจัตุรัส ก็มี ความกว้าง กับ ความสูง เหมือนกันนิน่า ดังนั้นเราก็แค่ทำ inheritance ซะก็จบแล้วนิ ตามรูปเลย

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

public class Square : Rectangle
{
    private double width;
    public new double Width
    {
        get { return width; }
        set
        {
            width = value;
            height = value;
        }
    }

    private double height;
    public new double Height
    {
        get { return height; }
        set
        {
            width = value;
            height = value;
        }
    }
}

นี่แหละคือตัวอย่างที่ คลาสลูกไม่สามารถแทนคลาสแม่ได้อย่างสมบูรณ์

❓ ทำไมคลาสลูกต้องสามารถแทนคลาสแม่ได้ล่ะ?

ความสัมพันธ์ของการทำ Inheritance นั้นเราเรียกว่า IS-A relationship นั่นหมายความว่า เวลาที่เราใช้คลาสที่สืบทอดกันมาเราก็จะคาดหวังว่าการทำงานในหลายๆส่วนจะมีพฤติกรรมที่เหมือนกับคลาสแม่ของมันด้วย เช่น มีคลาส Dog กับ Cat ที่สืบทอดจากคลาส Animal และสัตว์ทุกตัวสามารถส่งเสียงร้องได้ ตามรูปด้านล่างนี้

ซึ่งปรกติเวลาเราสั่งให้สัตว์มันส่งเสียงร้องจาก method Goes() เราก็จะคาดหวังให้มันส่งเสียงร้องใช่ไหม? เช่น หมาก็จะร้องโฮ่งๆ แมวก็ร้องเหมี๊ยวๆไรงี้ แต่ถ้าคลาสลูกไม่ได้ทำงานเปรียบเสมือนคลาสแม่ล่ะ ลองคิดดูว่าถ้าเราเรียกให้แมวมันร้องผ่าน method Goes() ไปปุ๊ป แต่สิ่งที่แมวมันทำคือ มันตีลังกาเต้น 3 ตลบ เราจะแปลกใจแค่ไหน ว่าทำไมเอ็งไม่ร้องฟร๊าาาา

ดังนั้นจากที่ว่ามา พอกลับไปที่ตัวอย่าง สี่เหลี่ยมผืนผ้า กับ สี่เหลี่ยมจัตุรัส ด้านบนบ้าง มันจะเกิดอะไรขึ้นถ้า method เราเขียนโค้ดตรวจสอบพื้นที่ไว้แบบนี้

public void TestCalculationAreaOfShape(Rectangle rec)
{
   rec.Width = 10;
   rec.Height = 5;
   if(rec.GetArea() != 50)
   {
      throw new Exception("การคำนวณพื้นที่ไม่ถูกต้อง")
   }
}

ถ้าเราส่ง Rectangle ไป มันจะทำงานได้ถูกต้องไม่มีปัญหาอะไร แต่พอเราส่ง Square ลงไปเท่านั้นแหละมันจะทำงานผิดทันที ทั้งๆที่การคำนวณพื้นที่มันถูกแล้วนะ แต่สิ่งที่มันทำให้โค้ดส่วนนี้ทำงานไม่ถูกคือ คลาสลูกไม่สามารถแทนคลาสแม่ได้นั่นเอง

สรุปสั้นๆจากการละเมิดกฎ LSP เราจะไม่สามารถเชื่อใจได้ว่าคลาสลูกจะนำมาใช้งานแทนคลาสแม่ได้เสมอไป !!!

การละเมิดกฎ LSP ก็เป็นการละเมิดกฎ OCP ด้วยเช่นกัน เพราะเราไม่สามารถใช้ abstraction มาทำงานเพื่อต่อยอดความสามารถได้ทุกครั้งไป (เรื่อง OCP ไปอ่านในบนก่อนหน้าเด้อ - ดูใน side menu เอา)

😕 แล้วจะออกแบบยังไงให้คลาสลูกแทนคลาสแม่ได้

เราลองมองกลับไปที่ Rectangle กับ Square กันก่อนว่าทำไมมันถึงมีปัญหากันล่ะ? . . . คำตอบก็คือ การทำ Inheritance นั้นเป็นความสัมพันธ์ในรูปแบบ IS-A ยังไงล่ะ

IS-A relationship ความสัมพันธ์ในรูปแบบนี้จะเกิดขึ้นได้ก็ต่อเมื่อของทั้งสองอย่างนั้นต้องมีพฤติกรรม (behavior) ที่เหมือนกันนั่นเอง ถึงควรจะมีความสัมพันธ์กับแบบ IS-A

ถ้าเรามองในฐานะคนเขียนโปรแกรม เราจะเห็นแค่ว่า Rectangle กับ Square มันมีตัวแปรที่ใช้ร่วมกันได้ เราก็เลยใช้ Inheritance ในจุดนั้น ซึ่งมันก็ไม่ได้ผิดในมุมของการ reuse code

ถ้าเรามองในหลักการออกแบบ เราจะพบว่า Rectangle กับ Square มันไม่ได้มีพฤติกรรมเหมือนกัน เพราะ Rectangle นั้นความกว้างกับความสูงมันไม่เท่ากันก็ได้ แต่ในขณะที่ Square ความกว้างกับความสูงต้องเท่ากันเสมอ ดังนั้นถ้ามองจากหลักการออกแบบแล้วจะพบว่า Square มันไม่ใช่กลุ่มเดียวกับ Rectangle ดังนั้นไม่ควรใช้ Inheritance นั่นเอง

Object-Oriented Design (OOD) มุ้งเน้นไปที่เรื่องการออกแบบโดยมองจากมุมพฤติกรรม behavior เป็นหลัก ดังนั้นถ้าเราปฏิบัติตาม LSP โค้ดเราก็จะได้หลัก OOD ไปด้วยในตัว

พออ่านมาถึงตรงนี้หลายๆคนก็เริ่มมึนๆแล้วว่า แล้วจะรู้ได้ยังไงว่าของแต่ละอย่างมันจะมีพฤติกรรมยังไง ต้องไปนั่งวิเคราะห์มันแต่ละตัวก่อนอีกเหรอ? คำตอบคือ(วิเคราะห์ก่อนก็ดีนะ) หรือเราสามารถใช้เทคนิคที่เรียกว่า Design by Contract หรือ Factoring ก็ได้

😄 Design by Contract (DBC)

เป็นการออกแบบโดยใช้ Code Contract เข้ามาช่วย วิธีทำคือเวลาที่เราอยากจะเขียนการทำงานซักอย่างนึงขึ้นมา เราก็จะไปกำหนดพฤติกรรมว่าของที่เราอยากได้คืออะไรทิ้งเอาไว้ ส่วนเมื่อไหร่ที่จะเขียนโค้ดการทำงานจริงๆก็ต้องเขียนโค้ดให้ตรงกับพฤติกรรมที่เรากำหนดไว้ในตอนแรกทั้งหมดด้วย

Code Contract สามารถเขียน Preconditions & Postconditions ได้ ้เพื่อใช้ตรวจสอบพฤติกรรมของโค้ดที่เขียนว่ามันเป็นไปตามที่เราต้องการหรือเปล่า

Code Contract อ่านเรื่องนี้เต็มๆได้จากลิงค์นี้ Microsoft: Code Contract

Unit testing เราสามารถใช้ unit tests เข้ามาช่วยตรวจสอบ Preconditions & Postconditions ของ Code Contract ได้ด้วยนะ เพื่อเอาไว้ตรวจว่าโค้ดที่เขียนขึ้นมาตรงตาม contract ที่ระบุไว้หรือไม่

😄 Factoring code

เป็นเทคนิกในการแยกของต่างๆที่ซ้ำกันออกมา แล้วเขียนเฉพาะของที่มีลักษณะเฉพาะตัวให้กับคลาสตัวนั้นๆ

จากตัวอย่างของ Rectangle กับ Square เราก็แค่แยกของที่ซ้ำกันออกมานั่นก็คือ การคำนวณพื้นที่ GetArea() ส่วนเรื่อง ความกว้าง กับ ความสูง ของคลาสทั้งสองตัวมันเป็นลักษณะเฉพาะของมัน ดังนั้นเราก็ควรแยกไปเป็นของใครของมันเลย ดังนั้นเราก็จะได้ออกมาเป็นโค้ดด้านล่างนี้

public abstract class Shape
{
    public double Width { get; set; }
    public double Height { get; set; }

    public Shape(double width, double height)
    {
        Width = width;
        Height = height;
    }

    public double GetArea()
    {
        return Width * Height;
    }
}

public class Rectangle : Shape
{
    public Rectangle(double width, double height)
        : base(width, height)
    {
    }
}

public class Square : Shape
{
    public Square(double widthOrHight)
        : base(widthOrHight, widthOrHight)
    {
    }
}

🎯 บทสรุป

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