Liskov 대체 원칙이 정말 유용합니까?

Liskov 대체는 SOLID 디자인의 일부입니다. 단단한?

SOLID are 5 software development principles or guidelines based on Object-Oriented design making it easier for you to make your projects scalable and maintainable.



모범 사례로 생각하십시오.

이제 Liskov 대체 란 무엇입니까



SOLID의 L은 이 원칙을 나타냅니다.

그것은 말한다

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. Barbara Liskov



솔직히 너무 과학적이다.

간단히 말해서

Replacing an instance of a class with its child class should not produce any negative side effects or broken codebase.



의미



✔️ 아무 것도 깨지 않고 부모 클래스를 사용하는 것과 동일하게 부모 클래스의 하위 클래스를 사용할 수 있습니다.
✔️ 하위 클래스는 상위 클래스 메서드를 수정/재정의할 수 있습니다.
❌ 서브클래스는 인수, 반환 유형 및 예외와 같은 부모의 메서드 서명을 수정할 수 있습니다.
❌ 하위 클래스는 상위 클래스에 없는 새로운 함수를 정의할 수 있습니다.
❌ 부모 클래스는 수정 가능합니다.

왜 이러는 거지?



이 원칙의 목표는 기본적으로 새 코드로 인해 이전 코드베이스가 손상되는 것을 방지하는 것입니다. 이것은 또한 및

설명을 위해 간단한 예를 사용하겠습니다.

간단한 사용 사례



다음 예는 규칙을 위반합니다.

class Animal{
    function eat(){
        // common functionality
        return "Eating Now" // return type string
    }

    function sleep(){
        // common functionality
        return "I am sleeping"  // return type string
    }
}

class Cat extends Animal{
    function eat(){
        // ... cat specific code
        return "Meow, whatever human"   // return type string
    }

    function sleep(){
        // ... cat specific code

        //  voilating LSP: parnet sleep() does not return boolean
        return true 
    }
}

class Dog extends Animal{
    function eat(){
        // ... dog specific code
        return "Woof, It was tasty."    // return type string
    }

    function sleep(){
        // ... dog specific code

        //  voilating LSP: parent sleep() doesn't use Error Exception
        throw Error('I just slept') 
    }
}



Liskov 대체 원칙을 사용하여 코드를 다음과 같이 수정합니다.

class Animal{
    function eat(){
        // common functionality
        return "Eating Now" // return type string
    }

    function sleep(){
        // common functionality
        return "I am sleeping"  // return type string
    }
}

class Cat extends Animal{
    function eat(){
        // ... cat specific code
        return "Meow, whatever human"   // return type string
    }

    function sleep(){
        // ... cat specific code
        return "I am already sleeping"  // return type string
    }
}

class Dog extends Animal{
    function eat(){
        // ... dog specific code
        return "Woof, It was actually tasty."   // return type string
    }

    function sleep(){
        // ... dog specific code
        return "Zzzzzzzz"   // return type string
    }
}


이 접근 방식을 사용하면 코드를 손상시키지 않고 부모 클래스와 자식 클래스를 바꿀 수 있습니다.

도움이 되나요?



대부분의 경우에 해당하지만 아래의 Birds 예와 같이 적합하지 않은 것을 더 추가하려는 경우가 있습니다.

class Bird{
    function fly(){}
}

class Duck extends Bird{}

class Ostrich extends Bird{} // Duck can fly but ostrich cant:


예, 정말 상황에 따라 다릅니다. 지나치게 복잡하거나 과도하게 설계되었거나 이해가 되지 않는 경우(예: 새 예) 자신의 일을 하는 것이 가장 좋습니다.



새 코드로 이전 코드를 확장하는 것은 쉽습니다. 이미 작동하는 코드를 손상시킬 염려 없이 새 클래스를 만들고 상위/기본 클래스로 확장하기만 하면 됩니다. 우리는 또한 원칙으로부터 이러한 이점을 얻습니다.


그래서 이것을 어떻게 보십니까? 정말 유용할 것 같죠? 의견에 귀하의 의견을 알려주십시오.

좋은 웹페이지 즐겨찾기