# 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** ขึ้นมาโดยเก็บ *ความกว้าง* กับ *ความสูง* และ สามารถคำนวณพื้นที่ได้ด้วย ตามโค้ดด้านล่างนี้

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

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

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

![](/files/-LnHSbhc1b5dF0NUNAFX)

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

```csharp
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** และ**สัตว์ทุกตัวสามารถส่งเสียงร้องได้** ตามรูปด้านล่างนี้

![](/files/-M1VIPUwLMo6ot_BbIax)

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

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

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

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

{% hint style="success" %}
**สรุปสั้นๆจากการละเมิดกฎ LSP**\
เราจะไม่สามารถเชื่อใจได้ว่าคลาสลูกจะนำมาใช้งานแทนคลาสแม่ได้เสมอไป !!!
{% endhint %}

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

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

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

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

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

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

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

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

### 😄 Design by Contract (DBC)

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

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

{% hint style="info" %}
**Code Contract**\
อ่านเรื่องนี้เต็มๆได้จากลิงค์นี้ [Microsoft: Code Contract](https://docs.microsoft.com/en-us/dotnet/framework/debug-trace-profile/code-contracts)
{% endhint %}

{% hint style="info" %}
**Unit testing**\
เราสามารถใช้ unit tests เข้ามาช่วยตรวจสอบ **Preconditions & Postconditions** ของ Code Contract ได้ด้วยนะ เพื่อเอาไว้ตรวจว่าโค้ดที่เขียนขึ้นมาตรงตาม contract ที่ระบุไว้หรือไม่
{% endhint %}

### 😄 Factoring code

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

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

![](/files/-LqwNOcCtSjBNiY5toxy)

```csharp
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 ไปในตัว**


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://www.saladpuk.com/basic/solid/lsp.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.