[오브젝트 : chap13] 서브클래싱과 서브타이핑

[오브젝트] chap13을 읽고

우리는 상속이 두 가지 용도로 사용된다는 사실을 이해해야 한다.

상속의 첫 번째 용도는 타입 계층을 구현하는 것이다. 타입 계층 안에서는 부모 클래스가 일반적인 개념을 구현하고 자식 클래스는 특수한 개념을 구현한다. 부모 클래스는 자식 클래스의 일반화이며 자식 클래스는 부모 클래스의 특수화이다. 타입 계층을 목표로 하는 상속은 다형적으로 동작하는 객체들의 관계에 기반해 확장 가능하고 유연한 설계를 얻을 수 있게 된다.

상속의 두 번째 용도는 코드 재사용이다. 상속은 간단한 선언만으로 부모 클래스의 코드를 재사용할 수 있지만 재사용을 위해 상속을 사용하는 경우 부모 클래스와 자식 클래스가 강하게 결합되기 때문에 변경하기 어려운 코드를 얻게 될 확률이 높다.

따라서 상속을 사용하는 일차적인 목표는 코드 재사용이 아니라 타입 계층을 구현하는 것이어야 한다.

이번 장에서는 올바른 타입 계층을 구성하는 원칙을 살펴볼 것이다. 그 전에 타입과 타입 계층의 개념에 대해 알아보자.

타입

개념 관점의 타입

개념 관점에서의 타입은 우리가 인지하는 세상의 사물의 종류를 의미한다. 즉, 우리가 인식하는 객체들에 적용하는 개념이나 아이디어를 가리켜 타입이라고 부른다. 어떤 대상이 타입으로 분류될 때 그 대상을 타입의 인스턴스라고 부른다. 자바, C++, 루비 등은 프로그래밍 언어 타입의 인스턴스이다.

프로그래밍 언어 관점의 타입

프로그래밍 언어 관점에서 타입은 비트 묶음에 의미를 부여하기 위해 정의된 제약과 규칙을 가리킨다. 프로그래밍 언어에서 타입은 두 가지 목적을 위해 사용된다.

• 타입에 수행될 수 있는 유효한 오퍼레이션의 집합을 정의한다.
• 타입에 수행되는 오퍼레이션에 대해 미리 약속된 문맥을 제공한다.

즉, 타입은 오퍼레이션의 종류와 의미를 정의한다. 이로써 개발자는 코드의 의미를 명확하게 전달할 수 있다.

객체지향 패러다임 관점의 타입

객체지향 프로그래밍에서 오퍼레이션은 객체가 수신할 수 있는 메시지를 의미한다. 따라서 객체의 타입이란 객체가 수신할 수 있는 메시지의 종류를 정의하는 것이다. 이를 퍼블릭 인터페이스라고 부른다.

즉, 객체지향에서 타입을 정의하는 것은 객체의 퍼블릭 인터페이스를 정의하는 것과 동일하다. 객체에게 중요한 것은 속성이 아니라 행동이기 때문에 객체들이 동일한 상태를 가지고 있더라도 퍼블릭 인퍼테이스가 다르마면 이들은 서로 다른 타입으로 분류된다.

객체를 바라볼 때는 항상 객체가 외부에 제공하는 행동에 초점을 맞춰야 한다 객체의 타입을 결정하는 것은 내부의 속성이 아니라 객체가 외부에 제공하는 행동이라는 사실을 기억하자.

타입 계층

타입 계측을 구성하는 두 타입간의 관계에서 더 일반적인 타입을 슈퍼타입이라고 부르고 더 특수한 타입을 서브타입이라고 부른다.

슈퍼타입이란 서브타입이 정의한 퍼블릭 인터페이스를 일반화시켜 상대저긍로 범용적이고 넓은 의미로 정의한 것이다. 서브타입이란 슈퍼타입이 정의한 퍼블릭 인터페이스를 특수화시켜 상대적으로 구체적이고 좁은 의미로 정의한 것이다.

언제 상속을 사용해야 하는가?

어떤 타입이 다른 타입의 서브타입이 되기 위해서는 어떤 조건을 만족할까? 또한 서브타입의 퍼블릭 인터페이스가 슈퍼타입의 퍼블릭 인터페이스보다 더 특수하다는 것은 어떤 의미일까?

상속의 올바른 용도는 타입 계층을 구현하는 것이다. 그렇다면 어떤 조건을 만족시켜야만 타입 계층을 위해 올바르게 상속을 사용했다고 말할 수 있을까? 다음 질문들에 모두 ‘예’라고 답할 수 있는 경우에만 그렇다.

• 상속 관계가 is-a 관계를 모델링하는가?
• 클라이언트 입장에서 부모 클래스의 타입으로 자식 클래스를 사용해도 무방한가?

is-a 관계

‘A는 B이다’라고 말할 수 있을 떄, is-a 관계가 성립한다. 다음 예시를 보자.

• 펭귄은 새다.
• 새는 날 수 있다.

분명히 펭귄은 새이지만 새의 정의에 날 수 있다는 행동이 포함된다면 펭귄은 새의 서브타입이 될 수 없다.

즉 타입 계층의 의미는 행동이라는 문맥에 따라 달라질 수 있다. 그에 따라 올바른 타입 계층이라는 의미 역시 문맥에 따라 달라질 수 있다. 따라서 슈퍼타입과 서브타입 관계에서는 is-a보다 행동 호환성이 더 중요하다.

따라서 어떤 두 대상을 언어적으로 is-a라고 표현할 수 있더라도 일단은 상속을 사용할 예비 후보 정도로만 생각해두자. 두 후보가 어떤 방식으로 사용되고 협력하는지 살펴본 후 상속의 적용여부를 결정해도 늦지 않다.

행동 호환성

펭귄과 새의 예ㅊ시처럼 타입의 이름 사이에 개념적으로 어떤 연고나성이 있다고 하더라도 행동에 연관성이 없다면 is-a 관계를 사용하지 말아야 한다.

결론은 두 타입 사이에 행동이 호환될 경우에만 타입 계층으로 묶어야 한다는 것이다. 그리고 중요한 것은 행동의 호환 여부를 판단하는 기준은 클라이언트의 관점이라는 것이다. 클라이언트가 두 타입이 동일하게 행동할 것이라고 기대한다면 두 타입을 타입으로 묶을 수 있다.

펭귄이 새가 될 수 없는 이유는 클라이언트 입장에서 모든 새가 날 수 있다고 가정하기 때문이다. 중요한 것은 클라이언트의 기대이다.

클라이언트의 기대에 따라 계층 분리하기

문제를 해결할 수 있는 방법은 클라이언트의 기대에 맞게 상속 계층을 분리하는 것이다.

위와 같이 날 수 있는 새와 펭귄을 분리하면 클라이언트의 기대에 따라 협력할 수 있다.

만약 새는 날 수 있으면서 걸을 수도 있어야하고, 펭귄은 걷기만 해야한다고 해보자. Bird는 Flyer과 Walker인터페이스를 구현하고 Penguin은 Walker인터페이스를 구현하면 된다.

그런데 여기서 Penguin이 Bird의 코드를 재사용해야한다면 어떻게될까? 바로 합성을 사용하면 된다. 물론 Bird의 퍼블릭 인터페이스만 사용할 수 있기 때문에 재사용하고자 하는 코드가 퍼블릭 인터페이스로 노출되어야 할 것이다. 노출되어 있지 않다면 Bird의 코드를 수정할 필요도 있을 것이다. 이것이 Penguin이 Bird를 상속하는 불필요한 상속 계층을 껴안고가는 것보다 훨씬 나은 방법이다.

클라이언트에 따라 인터페이스를 분리하면 변경에 대한 영향을 더 세밀하게 제어할 수 있게 된다. 클라이언트의 요구가 바뀌어도 영향의 파급효과를 효과적으로 제한할 수 있다.

만약 Flyer의 클라이언트의 요구가 변경된다면 변경의 영향은 Bird에서 끝난다.

이처럼 인터페이스를 클라이언트의 기대에 따라 분리함으로써 변경에 의한 영향을 제어하는 설계 원칙을 인터페이스 분리 원칙이라고 부른다.

주의해야 할 점은 설계가 꼭 현실 세계를 반영할 필요는 없다는 것이다. 오직 클라이언트가 객체에게 요구하는 행동에 기반하라. 자연어에 현혹되지 말고 요구사항 속에서 클라이언트가 기대하는 행동에 집중하자.

서브클래싱과 서브타이핑

결국 언제 상속을 사용해야 하는가에 대한 답은 ‘is-a 관계를 만족하고 행동이 호환되는 경우’이다. 쉽게 말하면 코드 재사용을 위한 상속이 아닌 타입 계층을 구성하기 위한 상속을 사용하라는 것이다.

사람들은 상속을 사용하는 두 가지 목적에 특별할 이름을 붙였다. 코드를 재사용할 목적으로 상속을 사용하는 서브클래싱과 타입 계층을 구성하기 위해 상속을 사용하는 서브타이핑이다.

취약한 기반 클래스 문제는 모두 코드 재사용을 위해 서브클래싱을 했기 때문에 벌어진 것이다.

서브타이핑 관계가 유지되기 위해서는 서브타입이 슈퍼타입이 하는 모든 행동을 동일하게 할 수 있어야 한다. 즉, 어떤 타입이 다른 타입의 서브타입이 되기 위해서는 행동 호한성을 만족시켜야 한다. 행동 호환성은 부모 클래스에 대한 자식 클래스의 대체 가능성을 포함한다.

리스코프 치환 원칙

행동 호환성과 대체 가능성은 올바른 상속 관계를 구축하기 위해 따라야 할 지침이다. 이 지침은 리스코프 치환 원칙이라는 이름으로 정리되어 소개되어 왔다.

리스코프 치환 원칙을 한마디로 정의하면 “서브타입은 그것의 기반 타입에 대해 대체 가능해야 한다.”라는 것이다. 즉, 클라이언트가 차이점을 인식하지 못한 채 기반 클래스의 인터페이스를 통해 서브클래스를 사용할 수 있어야 한다.

클라이언트와 대체 가능성

Stack과 Vector의 경우에도 부모 클래스인 Vector에게 기대하는 행동을 Stack에 대해서 기대할 수 없다. 즉, 행동 호환성을 만족시키지 못했다.

리스코프 치환 원칙을 위반하는 고전적인 사례인 Rectangle과 Square의 사례를 찾아보자. 부모 클래스에서 세운 가정이 자식 클래스에서 무너졌을 때 리스코프 치환 원칙은 무너지기 때문에, 구 클래스 사이의 관계는 서브클래싱 관계가 된다.

리스코프 치환 원칙은 자식 클래스가 부모 클래스를 대체하기 위해서는 부모 클래스에 대한 클라이언트의 가정을 준수해야 한다는 것을 강조한다. 자식 클래스에서 부모 클래스의 가정을 준수하지 않는다는 것은 부모와 자식이 서로 다른 클라이언트와 협력해야 한다는 것을 의미한다.

is-a 관계 다시 살펴보기

is-a 관계는 클라이언트 관점에서 is-a일 때만 참이다. is-a 관계는 객체지향에서 중요한 것은 객체의 속성이 아니라 객체의 행동이라는 점을 강조한다.

즉 클라이언트 입장에서 슈퍼타입과 서브타입의 호환성을 검증하고 호환된다면 두 타입을 is-a로 연결해 타입의 이름을 정하자.

리스코프 치환은 유연한 설계의 기반이다

리스코프 치완 원칙이 지켜진다면 클라이언트의 입장에서 부모와 자식 클래스의 행동 방식이 변경되지 않는다. 그러면 클라이언트의 코드를 변경하지 않고 새로운 자식 클래스와 협력할 수 있게 된다.

리스코프 치환 원칙을 지키면 코드 수정 없이 기능을 확장할 수 있기 때문에 개방-폐쇄 원칙을 만족하는 설계를 위한 전제 조건이다. 일반적으로 리스코프 치환 원칙 위반은 잠재적인 개방-폐쇄 원칙 위반이다.

계약에 의한 설계와 서브타이핑

[계약에 의한 설계는 추후에 정리하겠습니다.]