객체지향5대원칙-LSP(Liskov Substitution Principle) - 리스코프 치환 원칙

객체지향 5대원칙(SOILD)의 원칙중 L에 해당하는것으로 만약 S가 T의 기본 클래스라면

S의 객체를 T의 객체로 대체해도 프로그램은 정상적으로 동작해야 한다라는 원칙이다.

그럼 예를들어보자

형은 건축공이고 동생은 개발자가 있다고 하자

형과 동생은 모두 가족이지만 동생의 일을 형이 대신할수 없기때문에 대체할수 없는 리스코프 치환원칙에 위배된다.

이를 코드로 보면 다음과 같다.

<?php

class BuildingEngineering{

    public function do_work(){

        echo "집을 짓고 있다.";

    }

}

class Programmer{

    public function do_work(){

        echo "소프트웨어를 개발중입니다.";

    }

}

$buildingengineering = new BuildingEngineering();

$buildingengineering->do_work();

$programmer = new Programmer();

$programmer->do_work();

자 그럼 치환원칙을 따르도록 수정해 보겠습니다. 먼저 치환원칙을 따르게 할려면

Job이라는 기본 클래스가 필요하다.

이제 Job이라는 클래스 객체를 해당 하위인 BuildingEngineering, Programmer로 바꾸어도 올바르게

동작한다. 구체적인 코드를 구현하면 다음과 같다.

<?php

interface Job{

    public function do_work();

}

class BuildingEngineering implements Job{

    public function do_work(){

        echo "집을 짓고 있다.";

    }

}

class Programmer implements Job{

    public function do_work(){

        echo "소프트웨어를 개발중입니다.";

    }

}

function perform_work(Job $job){

    $job->do_work();

}

$buildingengineering = new BuildingEngineering();

$programmer = new Programmer();

perform_work($buildingengineering);

perform_work($programmer);

여기서 우리는 하위 유형으로 개체를 바꾸어도 동일한 처리를 하는것을 확인할수 있다.    

여기서 몇가지 설명을 더 붙이자면 리스코프 치환법칙은 동일한 결과에 초점이 맞춰저 있는게 아니라

상속받은 클래스나 인터페이스 사이에 계약관계로 동일한 흐름에 초점이 맞춰져 있다.

예를들어 BuildingEngineering에 do_work메소드를 호출했을때 예외상황이 발생한다면

Programmer의 dow_work와 같은 처리를 하지 않고 예외의 상황을 발생시키므로

LSP정책을 위반한다고 말할수 있다.