LSP

하위 타입 치환 가능성(Substitutability)은 LSP의 핵심 개념으로, 프로그램에서 기반 클래스(부모 클래스)의 객체가 사용되는 모든 곳에서 그 객체를 파생 클래스(자식 클래스)의 객체로 치환해도 프로그램의 정확성에 아무런 문제가 없어야 한다는 원칙이다.

이는 수학적 개념인 형식 명세(formal specification)와 계약에 기반을 둔다. 클래스 간의 상속 관계는 단순히 코드를 재사용하기 위한 수단이 아니라, "IS-A" 관계를 의미하는 타입 계층 구조를 정의한다. 따라서 하위 타입은 상위 타입이 제공하는 모든 공개 인터페이스(public interface)를 반드시 준수해야 하며, 상위 타입의 클라이언트가 기대하는 사전 조건(precondition)을 더 강화하거나 사후 조건(postcondition)을 더 약화시켜서는 안 된다[4].

이 원칙을 위반하는 전형적인 예는 직사각형 클래스를 상속받는 정사각형 클래스를 설계하는 경우이다. 정사각형은 수학적으로 직사각형의 일종이지만, setWidth와 setHeight 메서드를 개별적으로 변경할 수 있는 직사각형의 행동 계약을 정사각형이 깨뜨리게 된다. 클라이언트 코드가 직사각형 객체를 기대하고 너비만 설정했을 때, 정사각형 객체로 치환되면 높이도 함께 변경되는 부작용이 발생하여 프로그램의 정확성이 훼손된다.

LSP의 핵심인 하위 타입 치환 가능성은 단순한 구문 호환성을 넘어, 상위 타입과 하위 타입 사이의 행위적 계약을 준수하는 것을 요구합니다. 이 계약은 주로 사전 조건과 사후 조건으로 정의됩니다.

사전 조건은 메서드가 실행되기 전에 참이어야 하는 조건입니다. 하위 타입은 상위 타입이 정의한 사전 조건을 더 강화해서는 안 됩니다. 즉, 상위 타입이 요구하는 조건보다 더 많은 제약을 클라이언트에게 요구할 수 없습니다. 예를 들어, 상위 타입의 메서드가 '입력값이 0 이상이어야 한다'는 사전 조건을 가진다면, 하위 타입은 '입력값이 10 이상이어야 한다'고 강화할 수 없습니다. 이는 기존 클라이언트 코드가 하위 타입으로 치환되었을 때, 추가된 조건을 만족하지 못해 오류를 발생시킬 수 있기 때문입니다.

사후 조건은 메서드 실행이 종료된 후 보장되는 조건입니다. 하위 타입은 상위 타입이 보장하는 사후 조건을 약화시켜서는 안 되며, 동일하거나 더 강화할 수 있습니다. 예를 들어, 상위 타입의 메서드가 '반환값이 항상 양수임'을 보장한다면, 하위 타입도 이 조건을 반드시 만족시켜야 합니다. 또한, 불변식—객체의 생명주기 동안 항상 유지되어야 하는 조건—도 하위 타입에서 훼손되어서는 안 됩니다. 하위 타입이 상위 타입의 불변식을 깨는 상태를 도입하면, 상위 타입을 사용하는 로직의 정합성이 무너질 수 있습니다.

이러한 계약의 엄격한 준수는 클라이언트 코드가 구체적인 하위 타입의 구현 세부사항에 의존하지 않고, 추상화(상위 타입)에만 의존하여 안정적으로 동작할 수 있도록 보장합니다.

직사각형과 정사각형의 관계는 상속을 논할 때 흔히 등장하는 고전적인 예시이자, 리스코프 치환 원칙 위반의 대표적인 사례이다. 직관적으로는 "정사각형은 모든 변의 길이가 같은 직사각형이다"라고 생각할 수 있어, Square 클래스가 Rectangle 클래스를 상속받는 것이 자연스러워 보인다.

그러나 이 상속 관계는 행동 측면에서 문제를 일으킨다. 일반적으로 Rectangle 클래스는 setWidth(int w)와 setHeight(int h)라는 두 개의 독립적인 메서드를 제공한다. Square가 이 클래스를 상속받으면, 정사각형의 불변식—즉, 너비와 높이가 항상 같아야 한다는 조건—을 유지하기 위해 두 메서드를 오버라이드하여 한쪽 속성을 변경할 때 다른 쪽도 함께 변경하도록 구현해야 한다.

```java

// LSP를 위반하는 전형적인 예

class Square extends Rectangle {

@Override

void setWidth(int w) {

super.setWidth(w);

super.setHeight(w); // 높이도 강제로 변경

}

@Override

void setHeight(int h) {

super.setHeight(h);

super.setWidth(h); // 너비도 강제로 변경

}

}

```

이러한 구현은 Square 객체가 Rectangle 객체를 기대하는 코드 문맥에서 치환될 때 예상치 못한 동작을 초래한다. 예를 들어, Rectangle의 면적을 계산하는 함수가 너비를 5, 높이를 4로 설정했다면, 사용자는 면적이 20이 될 것이라 기대한다. 하지만 이 함수에 Square 객체가 전달되면, setHeight(4) 호출은 내부에서 setWidth(4)도 동시에 실행시켜 너비를 4로 변경해 버린다. 결과적으로 면적은 16이 되어 사용자의 기대를 저버린다[6].

이 문제의 핵심은 Square가 Rectangle의 *계약*을 완전히 준수하지 못하기 때문이다. Rectangle의 setWidth와 setHeight에 대한 사용자의 암묵적 기대는 "다른 한쪽 속성은 변하지 않는다"는 것이다. Square는 이 기대를 깨뜨리므로, Rectangle의 하위 타입으로서 치환 가능하지 않다. 이는 is-a 관계가 단순히 "일반-특수"의 개념적 관계가 아니라, 행동의 치환 가능성에 기반해야 함을 보여준다.

이 문제를 해결하는 한 가지 방법은 두 클래스가 공통의 추상 인터페이스(Shape 등)를 구현하되, 서로 독립적인 계층 구조로 만드는 것이다. 또는 너비와 높이를 동시에 설정하는 메서드(resize 등)를 도입하여, 두 클래스가 각자의 불변식을 유지할 수 있는 새로운 추상화를 제공하는 설계를 고려할 수 있다.

LSP 위반의 또 다른 흔한 형태는 기반 클래스의 메서드가 예외를 던지지 않는 반면, 파생 클래스의 오버라이딩된 메서드가 새로운 예외를 발생시키는 경우이다. 이는 클라이언트 코드가 기반 타입에 대해 가정한 '예외가 발생하지 않는다'는 계약을 파생 타입이 깨뜨리는 상황이다. 클라이언트는 특정 예외에 대한 처리 로직이 없기 때문에 프로그램이 비정상적으로 종료되거나 오동작할 수 있다.

동작의 의미적 변경 또한 심각한 LSP 위반 사례이다. 예를 들어, 기반 클래스의 정렬() 메서드가 오름차순 정렬을 수행한다고 명시되어 있다면, 파생 클래스에서 이를 오버라이딩하여 내림차순 정렬을 수행하는 것은 명백한 위반이다. 비록 메서드 시그니처(이름, 매개변수, 반환 타입)는 동일하더라도, 메서드가 제공하는 '사후 조건'이나 행위의 의미가 근본적으로 달라지기 때문이다. 클라이언트는 동일한 결과를 기대하지만 전혀 다른 결과를 받게 된다.

이러한 문제는 단순히 상속 관계를 잘못 설정했을 때 빈번히 발생한다. "is-a" 관계가 성립하지 않음에도 코드 재사용만을 목적으로 무리한 상속을 적용하면, 파생 클래스가 기반 클래스의 규약을 지키지 못하게 된다. 결과적으로, LSP를 위반한 코드는 다음과 같은 문제점을 보인다.

따라서, 상속을 설계할 때는 '행위적 호환성'에 집중해야 한다. 파생 클래스는 기반 클래스가 정의한 공개 인터페이스의 모든 명세(예외, 선행 조건, 사후 조건, 불변식)를 반드시 준수하거나 더 약화시켜야 하며, 이를 강화해서는 안 된다.

인터페이스 분리 원칙은 클라이언트가 사용하지 않는 메서드에 의존하지 않도록 광범위한 인터페이스를 더 작고 구체적인 인터페이스로 분리할 것을 권장한다. 이 원칙을 준수하면 LSP 위반 가능성을 줄이는 데 도움이 된다. 과도하게 많은 메서드를 가진 '뚱뚱한 인터페이스'는 하위 타입이 모든 메서드를 의미 있게 구현하기 어렵게 만들어, 일부 메서드에서 예외를 던지거나 무의미한 동작을 유발할 수 있기 때문이다.

인터페이스를 클라이언트의 필요에 따라 분리하면, 각 인터페이스는 더 명확하고 강력한 계약을 정의하게 된다. 이는 하위 타입이 그 계약을 완전히 준수해야 한다는 LSP의 요구사항과 맞닿아 있다. 예를 들어, Printer 인터페이스에 print, scan, fax 메서드가 모두 포함되어 있다면, 간단한 프린터는 스캔이나 팩스 기능을 구현할 수 없어 LSP를 위반할 수 있다. 대신 Printable, Scannable 등의 세분화된 인터페이스를 정의하고, 클래스가 필요한 인터페이스만 구현하도록 하는 것이 바람직하다.

명세는 인터페이스가 정의하는 계약을 문서화하거나 코드로 표현하는 것을 의미한다. 이는 메서드의 사전 조건, 사후 조건, 불변 조건을 포함한다. 명확한 명세는 LSP 준수를 검증하는 기준이 된다. 하위 타입은 상위 타입의 명세를 약화시키지 않고도 대체 가능해야 한다. 즉, 사전 조건을 더 강하게 만들거나[9], 사후 조건을 더 약하게 만들면 안 된다.

따라서, 인터페이스를 분리하고 그에 대한 명확한 명세를 작성하는 것은 하위 타입이 단일하고 명확한 책임을 지며, 상위 타입의 계약을 훼손하지 않도록 보장하는 핵심적인 설계 활동이다.

상속은 코드 재사용과 계층 구조 표현에 강력한 도구이지만, 리스코프 치환 원칙을 위반하기 쉬운 구조를 만들 수 있다. 상속은 부모 클래스의 구현 세부 사항에 자식 클래스가 강하게 결합되게 하여, 부모 클래스의 변경이 예상치 못하게 자식 클래스의 동작을 깨뜨릴 위험이 있다. 또한, 자식 클래스가 부모 클래스의 모든 메서드를 필요로 하지 않더라도 강제로 물려받아야 하는 경우가 발생하며, 이는 인터페이스 분리 원칙 위반으로 이어질 수 있다.

이에 대한 대안으로 컴포지션은 한 객체가 다른 객체를 포함하거나 참조하여 기능을 재사용하는 방식이다. 컴포지션은 "has-a" 관계를 형성하며, 런타임에 포함된 객체를 교체할 수 있어 유연성이 높다. 상속이 화이트박스 재사용이라면, 컴포지션은 블랙박스 재사용에 가깝다. 클라이언트는 포함된 객체의 내부 구현을 알 필요 없이 공개된 인터페이스를 통해 협력하므로, 결합도가 낮아지고 LSP를 준수하기 쉬워진다.

컴포지션을 적용할 때는 인터페이스를 통해 협력 관계를 정의하는 것이 좋다. 이는 구체적인 구현 클래스가 아닌 추상화에 의존하게 함으로써, 포함된 객체를 동일한 인터페이스를 만족하는 다른 구현체로 쉽게 교체할 수 있게 한다. 다음은 상속과 컴포지션의 주요 차이점을 비교한 표이다.

따라서, LSP를 고려한 설계에서는 상속을 사용하기 전에 컴포지션으로 요구사항을 충족할 수 있는지 먼저 검토하는 것이 바람직하다. 상속은 진정한 계층적 분류와 다형성이 필요한 경우에 제한적으로 사용하고, 기능 확장이나 코드 재사용의 주된 수단으로는 컴포지션과 인터페이스를 우선하는 것이 더 안정적인 설계로 이어진다. 이 접근법은 개방-폐쇄 원칙 준수에도 기여한다.

단일 책임 원칙(SRP)은 하나의 클래스가 변경되어야 하는 이유는 단 하나여야 한다는 원칙이다. 이 원칙은 클래스의 응집도를 높이고, 변경으로 인한 부작용을 최소화하는 데 목적이 있다. 리스코프 치환 원칙(LSP)은 SRP가 잘 지켜진 설계를 바탕으로 하위 타입의 치환 가능성을 보장하는, 보다 구체적인 행동 규약을 다룬다. SRP는 '무엇을 책임져야 하는가'에 초점을 맞춘다면, LSP는 '그 책임을 어떻게 올바르게 수행해야 하는가'에 초점을 맞춘다.

SRP를 위반하는 클래스, 즉 여러 책임을 지니고 있는 클래스는 자연스럽게 LSP 위반의 가능성을 높인다. 하나의 클래스가 다양한 책임을 수행하려면 그만큼 많은 공개 인터페이스를 노출하게 되고, 이는 하위 클래스가 모든 인터페이스를 올바르게 구현하기 어렵게 만든다. 하위 클래스는 부모 클래스의 일부 책임만 필요로 할 수 있지만, SRP 위반으로 인해 불필요한 인터페이스까지 강제로 상속받아 오버라이드해야 하는 상황이 발생한다. 이 과정에서 하위 클래스의 동작이 부모 클래스의 기대를 저버릴 가능성이 커지며, 이는 LSP 위반으로 이어진다.

반대로, SRP를 준수하여 각 클래스가 명확하고 단일한 책임을 가지면, LSP를 준수하기 위한 조건이 명확해진다. 책임이 단일하면 그에 따른 행동 계약도 단순하고 명확해지기 때문이다. 예를 들어, 저장소라는 책임만 가진 클래스는 데이터를 저장한다는 하나의 주요 계약을 갖는다. 이 클래스를 상속받는 파일 저장소나 데이터베이스 저장소는 그 단일한 책임을 어떻게 수행할지 구체화하면 되므로, LSP를 지키며 부모 타입을 대체하기 쉬워진다. 따라서 SRP는 LSP를 실현하기 위한 필수적인 선결 조건으로 작용한다고 볼 수 있다.

결론적으로, 두 원칙은 서로 보완적 관계에 있다. SRP는 모듈의 내부 구조와 책임의 분리를 통해 변경의 축을 관리하고, LSP는 그러한 모듈들이 다형성을 통해 안전하게 협력할 수 있도록 외부 행동의 일관성을 보장한다. 잘 설계된 시스템은 SRP를 통해 견고한 구성 요소를 만들고, LSP를 통해 그 구성 요소들을 유연하게 조합할 수 있게 된다.

인터페이스 분리 원칙(ISP)은 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙이다. 이 원칙은 하나의 거대한 인터페이스를 여러 개의 구체적이고 작은 인터페이스로 분리하는 것을 권장한다. 반면, 리스코프 치환 원칙(LSP)은 상위 타입의 객체를 하위 타입의 객체로 치환해도 프로그램의 정확성이 깨지지 않아야 한다는 원칙에 초점을 맞춘다.

두 원칙의 핵심 차이는 문제 해결의 접근 방식과 범위에 있다. ISP는 주로 인터페이스의 설계와 클라이언트의 의존성을 다룬다. 불필요한 메서드로 인한 인터페이스 오염을 방지하여 시스템의 결합도를 낮추고 유연성을 높이는 것이 목표이다. 예를 들어, Printer 인터페이스에 print, scan, fax 메서드가 모두 선언되어 있다면, 단순 인쇄만 필요한 클라이언트는 사용하지 않는 scan과 fax 메서드에 의존하게 된다. ISP는 이를 Printer, Scanner, FaxMachine 인터페이스로 분리할 것을 제안한다.

LSP는 이보다 더 근본적인 행위의 호환성과 계약 준수를 다룬다. ISP가 인터페이스의 '크기'와 '의존성'에 주목한다면, LSP는 상속 계층 구조 내에서의 '행위의 일관성'을 강조한다. LSP 위반은 ISP를 준수하는 작은 인터페이스에서도 발생할 수 있다. 예를 들어, Bird 인터페이스에 fly() 메서드만 있다 하더라도, 이를 상속받은 Penguin 클래스가 fly() 메서드를 예외를 발생시키거나 아무 동작도 하지 않도록 구현한다면, 이는 ISP는 지켰지만 LSP를 위반한 사례가 된다.

요약하면, ISP는 인터페이스를 클라이언트 중심으로 세분화하여 불필요한 결합을 피하도록 안내하는 구조적 설계 원칙이다. LSP는 하위 타입이 상위 타입의 기대 행위와 계약을 반드시 유지하도록 요구하는 행위적 상속 원칙이다. 효과적인 객체 지향 설계를 위해서는 두 원칙을 상호 보완적으로 적용해야 한다.

단위 테스트는 LSP 준수 여부를 검증하는 실용적이고 효과적인 도구이다. 클라이언트 코드의 관점에서 작성된 테스트는 하위 타입이 기대되는 계약을 완전히 이행하는지 확인하는 객관적인 기준을 제공한다.

구체적인 검증 방법은 기반 클래스나 인터페이스에 대한 테스트 스위트를 먼저 작성하는 것이다. 이후 이 테스트 스위트를 파생 클래스의 인스턴스로 실행하여 모든 테스트가 통과하는지 확인한다. 만약 파생 클래스가 테스트를 실패한다면, 그것은 하위 타입 치환 가능성을 위반했을 가능성이 높다. 예를 들어, Bird 클래스에 fly() 메서드에 대한 테스트가 있고, Penguin 클래스가 Bird를 상속받았다면, Penguin 인스턴스로 fly() 테스트를 실행할 때 문제가 발생할 수 있다. 이는 LSP 위반을 암시하는 신호이다.

테스트 작성 시에는 메서드의 사전 조건과 사후 조건, 불변식을 명확히 정의하는 것이 중요하다. 단위 테스트는 이러한 계약을 검증하는 구체적인 사례가 된다. 또한 모의 객체를 사용하여 클라이언트의 관점에서 상호작용을 테스트하면, 하위 타입이 상위 타입과 동일한 방식으로 협력 객체와 소통하는지 확인할 수 있다. 이 접근법은 행동의 치환 가능성을 보장하는 데 도움을 준다.

코드 리팩토링 과정에서 LSP를 준수하는지는 시스템의 안정성을 보장하는 핵심 요소이다. 리팩토링은 외부 동작을 변경하지 않고 내부 구조를 개선하는 작업이므로, 기존 클라이언트 코드가 기대하는 계약을 깨뜨리지 않아야 한다. 특히 상속 관계를 수정하거나 인터페이스를 변경할 때는 하위 타입이 상위 타입을 완전히 대체할 수 있는지 철저히 검증해야 한다.

리팩토링 시 구체적인 고려사항은 다음과 같다. 첫째, 메서드의 사전 조건을 강화하거나 사후 조건을 약화시키지 않아야 한다. 예를 들어, 기존 메서드가 null을 입력받을 수 있었다면, 리팩토링 후 하위 클래스에서 null 입력을 금지하는 것은 LSP 위반이다. 둘째, 예외의 종류를 변경하거나 새로운 검사 예외를 추가하지 않아야 한다. 클라이언트가 기대하지 않은 예외가 발생하면 프로그램의 흐름이 깨질 수 있다.

마지막으로, 리팩토링 후에는 반드시 기존 단위 테스트를 모두 통과하는지 확인해야 한다. 이 테스트들은 클라이언트의 관점에서 기대하는 동작을 정의한 계약의 역할을 한다. 만약 리팩토링으로 인해 테스트가 실패한다면, 이는 하위 타입이 상위 타입의 동작을 변경했음을 의미하며, LSP 위반 가능성을 시사한다. 따라서 리팩토링은 테스트 주도로 진행하고, 상속 계층 구조의 변경 시에는 해당 타입을 사용하는 모든 클라이언트 코드의 영향을 평가하는 것이 안전하다.

전략 패턴은 행위 패턴의 일종으로, 실행 중에 알고리즘을 선택할 수 있게 하는 디자인 패턴이다. 이 패턴은 특정 작업을 수행하는 여러 알고리즘이 존재하고, 클라이언트가 런타임에 적절한 알고리즘을 결정해야 할 때 유용하게 적용된다. 전략 패턴의 핵심은 알고리즘 군을 정의하고 각각을 별도의 클래스로 캡슐화하여, 이들을 상호 교환 가능하게 만드는 것이다.

이 패턴은 일반적으로 세 가지 주요 구성 요소로 이루어진다. 첫째는 모든 구체적인 전략 클래스가 구현해야 하는 공통 인터페이스인 Strategy 인터페이스이다. 둘째는 이 인터페이스를 구현하는 하나 이상의 ConcreteStrategy 클래스들이다. 셋째는 Strategy 인터페이스를 참조하여 사용하는 Context 클래스이다. Context는 구체적인 전략 객체에 대한 의존성을 주입받아, 그 객체에게 실제 작업을 위임한다.

전략 패턴은 LSP 준수와 밀접한 관련이 있다. 각 ConcreteStrategy 클래스는 Strategy 인터페이스의 계약을 완전히 준수해야 하며, 클라이언트(Context)는 구체적인 전략의 종류에 관계없이 동일한 방식으로 상호작용할 수 있어야 한다. 이는 곧 모든 구체적 전략이 상위 타입(Strategy)을 완전히 대체할 수 있어야 함을 의미하며, LSP의 핵심인 하위 타입 치환 가능성을 잘 보여준다. 예를 들어, 정렬 알고리즘을 QuickSortStrategy와 MergeSortStrategy로 구현했다면, Context는 이 둘을 아무 문제 없이 교체하며 사용할 수 있어야 한다.

템플릿 메서드 패턴은 LSP 준수를 촉진하는 대표적인 행위 패턴이다. 이 패턴은 알고리즘의 골격을 슈퍼클래스에 정의된 템플릿 메서드로 제공하고, 알고리즘의 특정 단계들은 서브클래스에서 재정의하도록 한다. 핵심은 템플릿 메서드가 호출하는 훅 메서드나 추상 메서드의 구현이 부모 클래스가 정의한 사전/사후 조건을 깨뜨리지 않는 것이다.

패턴을 적용할 때는 서브클래스가 템플릿 메서드의 흐름을 역전시키지 않아야 한다. 예를 들어, 부모 클래스의 템플릿 메서드가 initialize() -> execute() -> cleanup() 순서로 메서드를 호출한다면, 모든 서브클래스는 이 순서를 변경해서는 안 된다. 서브클래스는 각 단계의 구체적인 내용만 변경할 뿐, 알고리즘의 전체 구조와 각 단계 간의 계약을 준수해야 한다.

이 패턴은 LSP를 잘 지키면 코드 재사용과 확장성을 높이지만, 위반하면 알고리즘의 정합성이 깨질 수 있다. 따라서 템플릿 메서드 패턴을 사용할 때는 서브클래스가 부모 클래스의 템플릿 메서드를 올바른 컨텍스트에서 대체할 수 있도록 설계하는 것이 중요하다.