Liskov 대체 원칙이 정말 유용합니까?
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:
예, 정말 상황에 따라 다릅니다. 지나치게 복잡하거나 과도하게 설계되었거나 이해가 되지 않는 경우(예: 새 예) 자신의 일을 하는 것이 가장 좋습니다.
팁
새 코드로 이전 코드를 확장하는 것은 쉽습니다. 이미 작동하는 코드를 손상시킬 염려 없이 새 클래스를 만들고 상위/기본 클래스로 확장하기만 하면 됩니다. 우리는 또한 원칙으로부터 이러한 이점을 얻습니다.
그래서 이것을 어떻게 보십니까? 정말 유용할 것 같죠? 의견에 귀하의 의견을 알려주십시오.
Reference
이 문제에 관하여(Liskov 대체 원칙이 정말 유용합니까?), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/rhuzaifa/is-the-liskov-substitution-principle-really-useful-3oce텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)