리스코프 치환 원칙편집자 확인

리스코프 치환 원칙은 1987년 바바라 리스코프가 발표한 논문 "데이터 추상화와 계층 구조"에서 제시된 개념이다. 이 원칙은 객체 지향 프로그래밍에서 하위 타입의 관계를 정의하는 핵심 규칙을 제공한다.

리스코프 치환 원칙의 공식적 정의는 다음과 같다. "S 타입의 객체 o1 각각에 대해, T 타입의 객체 o2가 있고, T에 의해 정의된 모든 프로그램 P에서 o2의 자리에 o1을 치환해도 P의 행동이 변하지 않는다면, S는 T의 하위 타입이다." 간단히 말해, 상위 타입 T를 사용하는 모든 프로그램은 하위 타입 S의 객체로 대체되어도 정확히 동일하게 작동해야 한다는 것이다.

이 정의는 수학적 치환 가능성에 기반을 두며, 다형성의 올바른 사용을 보장한다. 원칙의 핵심은 상속이 단순히 코드 재사용을 위한 메커니즘이 아니라, 행동의 호환성을 보장하는 계약의 관계여야 함을 강조한다. 따라서 하위 클래스는 상위 클래스가 제공하는 공개 인터페이스의 규약을 반드시 준수해야 한다.

이 원칙은 타입 시스템의 이론적 기초를 넘어, 실제 소프트웨어 설계에서 인터페이스 분리 원칙 및 의존 관계 역전 원칙과 함께 작동하여 유연하고 견고한 시스템을 구축하는 데 기여한다.

행동적 하위 타입은 리스코프 치환 원칙을 준수하는 하위 클래스가 가져야 할 핵심 속성을 설명하는 개념이다. 이 개념은 단순히 프로그래밍 언어의 구문적 상속 관계(예: extends 또는 implements)를 넘어, 타입의 사용 가능한 행동에 초점을 맞춘다. 즉, 어떤 타입 S가 타입 T의 행동적 하위 타입이 되려면, T의 객체를 기대하는 모든 프로그램에서 S의 객체로 치환해도 프로그램의 정확성이 깨지지 않아야 한다[1].

행동적 하위 타입 관계를 검증하기 위해서는 상위 타입이 정의한 계약을 하위 타입이 준수하는지 확인해야 한다. 이 계약은 메서드의 사전 조건, 사후 조건, 그리고 불변식으로 구성된다. 행동적 하위 타입은 다음과 같은 규칙을 따라야 한다.

* 사전 조건 약화: 하위 타입의 메서드는 상위 타입의 메서드보다 더 약한(덜 제한적인) 사전 조건을 가질 수 있다. 즉, 상위 타입이 요구하는 조건보다 더 넓은 입력을 받아들일 수 있다.

* 사후 조건 강화: 하위 타입의 메서드는 상위 타입의 메서드보다 더 강한(더 제한적인) 사후 조건을 가져야 한다. 즉, 상위 타입이 보장하는 결과보다 더 구체적이고 엄격한 결과를 보장해야 한다.

* 불변식 유지: 하위 타입은 상위 타입이 정의한 모든 불변식을 반드시 유지해야 하며, 추가적인 불변식을 도입할 수 있다.

이 접근법은 "is-a" 관계를 구문이 아닌 의미론과 행동으로 재정의한다. 예를 들어, 수학적으로 "정사각형은 직사각형이다"라는 명제는 참이지만, 가변적인 setWidth와 setHeight 메서드를 가진 클래스 계층 구조에서는 Square가 Rectangle의 행동적 하위 타입이 되지 못한다[2]. 따라서 행동적 하위 타입은 상속의 올바른 사용을 위한 실용적인 지침을 제공한다.

직사각형-정사각형 문제는 리스코프 치환 원칙을 위반하는 고전적인 사례로 자주 인용된다. 이 문제는 객체 지향 프로그래밍에서 상속 관계를 직관적으로 모델링할 때 발생할 수 있는 함정을 보여준다. 수학적으로 정사각형은 직사각형의 특수한 경우이므로, Square 클래스가 Rectangle 클래스를 상속받는 것은 자연스러워 보인다. 그러나 이 상속 관계는 객체의 행동 측면에서 문제를 일으킬 수 있다.

일반적인 Rectangle 클래스는 setWidth와 setHeight 메서드를 독립적으로 제공한다. 반면 Square는 너비와 높이가 항상 같아야 하므로, 한쪽을 설정할 때 다른 쪽도 함께 변경되어야 한다. 만약 Square가 Rectangle을 상속받고 setWidth 메서드를 오버라이드하여 높이도 함께 변경하도록 구현하면, 클라이언트 코드에 예기치 않은 영향을 미친다.

예를 들어, Rectangle 객체의 너비를 증가시키는 다음 함수를 고려해 보자.

```java

void increaseWidth(Rectangle r) {

r.setWidth(r.getWidth() + 10);

}

```

이 함수는 인자로 Rectangle의 인스턴스를 받는다. 다형성에 따라 Square 인스턴스를 이 함수에 전달할 수 있다. 그러나 increaseWidth 함수는 Rectangle의 행동을 가정하고 작성되었기 때문에, Square의 setWidth 메서드가 높이까지 변경한다는 사실을 알지 못한다. 결과적으로 Square 객체의 면적은 예상과 다르게 변할 수 있으며, 이는 리스코프 치환 원칙 위반이다. Square는 Rectangle을 대체했을 때 프로그램의 정확성을 해치지 않아야 하지만, 실제로는 그렇지 않다.

이 문제의 해결책은 행동 호환성에 초점을 맞추는 것이다. Square와 Rectangle 사이에 IS-A 관계가 성립하더라도, 두 클래스의 불변식과 메서드의 계약이 충돌하면 상속을 사용해서는 안 된다. 대신 두 클래스가 공통의 인터페이스나 추상 클래스(예: Shape)를 구현하거나, 컴포지션을 사용하는 등의 대안을 고려할 수 있다. 이 사례는 상속을 결정할 때 "is-a" 관계보다 "행동적으로 대체 가능한가"라는 질문이 더 중요함을 보여준다.

리스코프 치환 원칙 위반은 여러 가지 일반적인 패턴으로 나타납니다. 이러한 패턴들은 대체로 부모 클래스가 정의한 계약을 자식 클래스가 약화시키거나 무효화함으로써 발생합니다.

하위 타입이 상위 타입의 사전 조건을 강화하거나 사후 조건을 약화시키는 경우가 대표적입니다. 예를 들어, 상위 타입의 메서드가 값 >= 0을 사전 조건으로 요구한다면, 하위 타입은 이를 값 > 0으로 강화해서는 안 됩니다. 이는 상위 타입이 허용하는 입력(0)을 하위 타입이 거부하게 만들어 치환 가능성을 깨뜨립니다. 반대로, 상위 타입이 반환값 != null을 사후 조건으로 보장한다면, 하위 타입이 null을 반환할 수 있도록 약화시키는 것도 위반입니다.

또 다른 흔한 위반 패턴은 하위 타입이 상위 타입과 관련 없는 새로운 예외를 발생시키는 것입니다. 이는 상위 타입을 사용하는 클라이언트 코드가 처리하지 않은 예외에 직면하게 만들어 시스템의 안정성을 해칩니다. 마지막으로, 하위 타입이 상위 타입의 특정 메서드를 "역할 거부" 방식으로 구현하는 경우도 있습니다. 예를 들어, fly() 메서드를 가진 Bird 클래스를 상속받은 Penguin 클래스가 fly() 메서드를 아무 동작도 하지 않거나 UnsupportedOperationException을 던지도록 구현하는 것이 이에 해당합니다. 이는 "새는 난다"는 상위 타입의 암묵적 계약을 하위 타입이 위반하는 사례입니다.

계약에 의한 설계(Design by Contract, DbC)는 리스코프 치환 원칙을 준수하기 위한 구체적인 방법론으로, 소프트웨어 구성 요소 간의 상호작용을 명확한 계약 조건으로 정의하는 접근법이다. 이 개념은 버트란드 메이어(Bertrand Meyer)가 제안했으며, 에펠(Eiffel) 프로그래밍 언어에 구현되었다. 계약에 의한 설계는 클라이언트(호출자)와 공급자(피호출자, 예: 슈퍼클래스 또는 서브클래스) 간의 의무와 이익을 사전 조건, 사후 조건, 불변식으로 명시한다.

계약의 세 가지 주요 요소는 다음과 같다.

리스코프 치환 원칙은 이 계약 관계를 하위 타입에 적용한다. 서브클래스는 상위 클래스와의 계약을 위반해서는 안 된다. 구체적으로, 서브클래스의 메서드는 상위 클래스 메서드의 사전 조건보다 더 강력한(제한적인) 요구사항을 가져서는 안 되며, 사후 조건과 불변식은 상위 클래스의 것보다 더 약해져서는 안 된다[4]. 이 규칙을 지키면 클라이언트 코드는 자신이 상위 클래스와 맺은 계약을 신뢰한 채, 하위 타입의 객체를 안전하게 치환하여 사용할 수 있다. 계약에 의한 설계는 이러한 규칙을 명시적으로 정의하고 검증함으로써 리스코프 치환 원칙의 실질적인 준수를 도와준다.

계약에 의한 설계에서 핵심을 이루는 요소는 사전 조건과 사후 조건, 그리고 불변 조건입니다. 이들은 메서드나 서브루틴의 호출자와 피호출자 사이의 명시적 계약을 정의합니다.

사전 조건은 메서드가 올바르게 실행되기 위해 호출자가 반드시 만족시켜야 하는 조건입니다. 예를 들어, 매개변수 값이 특정 범위 내에 있어야 하거나, 객체가 특정 상태여야 할 수 있습니다. 리스코프 치환 원칙에 따르면, 하위 클래스의 메서드는 상위 클래스의 메서드보다 더 강력한 사전 조건을 요구해서는 안 됩니다. 즉, 하위 클래스는 상위 클래스가 받아들일 수 있는 모든 입력을 동일하게 받아들여야 합니다. 사전 조건을 강화하면, 상위 클래스 인스턴스가 동작하던 컨텍스트에서 하위 클래스 인스턴스로 치환했을 때, 기존에 유효했던 입력이 새로 강화된 조건에 의해 거부될 수 있기 때문입니다.

반대로, 사후 조건은 메서드 실행이 성공적으로 종료된 후에 보장되는 조건입니다. 이는 반환 값의 상태나 객체의 상태 변화를 포함할 수 있습니다. 리스코프 치환 원칙은 하위 클래스의 메서드가 상위 클래스의 메서드보다 더 약한 사후 조건을 제공해서는 안 된다고 요구합니다. 하위 클래스는 상위 클래스가 보장하는 모든 결과와 상태 변화를 최소한 그대로 보장해야 하며, 추가적인 보장을 할 수는 있습니다. 사후 조건을 약화시키면, 호출자가 상위 클래스로부터 기대했던 보장을 하위 클래스가 제공하지 못하게 되어 시스템의 신뢰성이 떨어집니다.

이러한 조건들을 준수함으로써, 하위 타입의 객체는 상위 타입의 객체를 대체했을 때 호출자의 관점에서 계약의 차이를 인지하지 못하게 됩니다. 이는 행동적 하위 타입의 개념을 실현하는 구체적인 방법이 됩니다.

자바의 컬렉션 프레임워크는 리스코프 치환 원칙을 잘 보여주는 대표적인 사례이다. List, Set, Map과 같은 상위 수준의 인터페이스와 ArrayList, LinkedList, HashSet, TreeMap과 같은 구체적인 구현 클래스들이 그 관계를 구성한다. 예를 들어, List 인터페이스는 순서가 있는 컬렉션의 동작을 정의하며, 이를 구현하는 ArrayList나 LinkedList는 그 계약을 준수하면서 내부 구현 방식은 다르다. 클라이언트 코드는 List 타입으로 객체를 참조하고, add(), get(), remove()와 같은 메서드를 호출할 때 구체적인 구현 클래스가 무엇인지 알 필요 없이 일관된 행동을 기대할 수 있다.

이 원칙의 준수는 다형성을 통한 유연한 설계를 가능하게 한다. 아래 표는 주요 컬렉션 인터페이스와 그 구현체의 예시를 보여준다.

Collections.unmodifiableList()와 같은 메서드가 반환하는 불변 리스트도 이 원칙을 따르는 좋은 예다. 이 메서드는 기존 리스트를 감싸서 수정 작업(add, remove 등)을 금지시키지만, List 인터페이스 타입으로 반환한다. 클라이언트는 이를 일반 List처럼 사용할 수 있으나, 수정을 시도하면 예외가 발생한다. 이는 하위 타입(UnmodifiableList)이 상위 타입(List)의 계약 중 '읽기' 관련 계약은 완전히 준수하면서, '쓰기' 계약에 대해서는 사전 조건을 강화하여[5] 명시적으로 금지하는 방식으로 동작한다. 이는 상위 타입의 기대 행동을 깨뜨리지 않는 범위 내에서의 변형으로 이해될 수 있다.

따라서 컬렉션 프레임워크는 클라이언트 코드가 추상화에 의존하게 함으로써 구현체를 자유롭게 교체할 수 있는 유연성을 제공하며, 이는 리스코프 치환 원칙이 설계의 기초에 잘 녹아들어가 있기 때문에 가능하다.

스트림 API는 자바 8에서 도입된 기능으로, 데이터 소스의 요소들을 선언적이고 함수형 스타일로 처리하기 위한 추상화를 제공한다. 이 API는 리스코프 치환 원칙을 잘 반영하는데, 핵심 인터페이스인 Stream<T>와 그 하위 스트림(IntStream, LongStream, DoubleStream) 사이의 관계가 원칙을 준수하기 때문이다. 숫자형 특화 스트림은 BaseStream 인터페이스를 공통으로 상속받으며, Stream 인터페이스의 일반적인 연산(filter, map, reduce 등)을 그대로 사용할 수 있다. 이는 클라이언트 코드가 Stream<Integer>를 기대하는 곳에 IntStream을 사용하더라도 예상된 동작을 보장함을 의미한다.

스트림 파이프라인의 각 단계(중간 연산)는 불변성을 유지하며 새로운 스트림을 반환하는데, 이 설계는 LSP의 핵심인 '행동 호환성'을 강화한다. 예를 들어, sorted()나 distinct() 같은 상태 저장 중간 연산을 적용해도 원본 데이터 소스를 변경하지 않으며, 단순히 새로운 스트림을 생성한다. 이는 상위 타입인 Stream이 제공하는 연산의 계약을 하위 구현체가 깨뜨리지 않음을 보여준다. 또한 최종 연산(collect, forEach)은 파이프라인의 결과를 소비하는 일관된 방식을 제공하여, 클라이언트가 스트림의 구체적인 타입을 알지 못해도 안전하게 사용할 수 있게 한다.

스트림 API의 또 다른 LSP 준수 사례는 반환 타입의 공변성과 관련 있다. Stream.map() 연산은 Function 매퍼를 적용한 후 새로운 Stream<R>을 반환한다. 이때 IntStream.map()은 IntUnaryOperator를 받아 IntStream을 반환하는 등, 특화된 스트림 타입은 자신의 타입을 유지하는 더 구체적인 연산을 제공한다. 이는 상위 타입의 연산을 더 제한적으로(공변적으로) 오버라이드하여, 기대하는 반환 타입의 하위 타입을 돌려줌으로써 LSP를 준수한다. 클라이언트는 Stream 인터페이스만으로 모든 스트림을 동일하게 다룰 수 있으며, 특화된 스트림이 추가적인 효율성(오토박싱 방지)을 제공하더라도 기본 계약을 위반하지 않는다.

이러한 설계 덕분에 개발자는 List<Integer>를 IntStream으로 변환하여 성능을 높이거나, Stream<String>과 동일한 패러다임으로 코드를 작성할 수 있다. 스트림 API는 추상화와 다형성을 통해 LSP가 추구하는 대체 가능성을 구체적인 라이브러리 수준에서 실현한典型案例이다.