서브클래싱과 서브타이핑

상속의 두가지 용도

타입 계층을 구현

 - 부모 클래스는 일반적인 개념을 구현하고 자식 클래스는 특수한 개념을 구현

 - 부모 클래스는 자식 클래스의 일반화(generalization), 자식 클래스는 부모 클래스의 특수화(specialization)

코드 재사용

 - 간단한 선언만으로 부모 클래스의 코드를 재사용함

 - 점진적으로 애플리케이션의 기능을 확장할 수 있음

 - 부모 클래스와 자식 클래스가 강하게 결합되기 때문에 변경하기 어려운 코드를 얻게 될 확률이 높음

상속을 사용하는 일차적인 목표는 코드 재사용이 아니라 타입 계층을 구현하는 것

타입 사이의 관계를 고려하지 않은 채 단순히 코드를 재사용하기 위해 상속을 사용해서는 안 된다

타입

개념 관점의 타입

 - 우리가 인지하는 세상의 사물의 종류

 - 우리가 인식하는 객체들에 적용하는 개념이나 아이디어

 - 심볼(symbol) : 타입에 이름을 붙인 것 (ex : 프로그래밍 언어)

 - 내연(intension) : 타입의 정의로서 타입에 속하는 객체들이 가지는 공통적인 속성이나 행동 (ex : 컴퓨터에게 특정한 작업을 지시하기 위한 어휘와 문법의 집합)

 - 외연(extension) : 타입에 속하는 객체들의 집합 (ex : 자바, 루비, 자바스크립트, C)

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

 - 연속적인 비트에 의미와 제약을 부여하기 위해 사용

 - 타입에 수행될 수 있는 유효한 오퍼레이션의 집합을 정의

 - 타입에 수행되는 오퍼레이션에 대해 미리 약속된 문맥을 제공

 - 적용 가능한 오퍼레이션의 종류와 의미를 정의함으로써 코드의 의미를 명확하게 전달하고 개발자의 실수를 방지하기 위해 사용

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

 - 객체가 수신할 수 있는 메시지의 종류를 정의하는 것

 - 퍼블릭 인터페이스 : 객체가 수신할 수 있는 메시지의 집합 

 - 동일한 퍼블릭 인터페이스를 가지는 객체들은 동일한 타입으로 분류

타입 계층

타입 계층을 구성하는 두 타입 간의 관계에서 더 일반적인 타입을 슈퍼타입(superType)이라고 부르고 더 특수한 타입을 서브타입(subType)이라고 한다

일반화 - 다른 타입을 완전히 포함하거나 내포하는 타입을 식별하는 행위 또는 그 행위의 결과

특수화 - 다른 타입 안에 전체적으로 포함되거나 완전히 내포되는 타입을 식별하는 행위 또는 그 행위의 결과

슈퍼타입 

 - 집합이 다른 집합의 모든 멤버를 포함한다

 - 타입 정의가 다른 타입보다 좀 더 일반적임

 - 서브타입이 정의한 퍼블릭 인터페이스를 일반화시켜 상대적으로 범용적이고 넓은 의미로 정의한 것

서브타입

 - 집합에 포함되는 인스턴스들이 더 큰 집합에 포함된다

 - 타입 정의가 다른 타입보다 좀 더 구체적임

 - 슈퍼타입이 정의한 퍼블릭 인터페이스를 특수화시켜 상대적으로 구체적이고 좁은 의미로 정의한 것

서브클래싱과 서브타이핑

상속을 사용해도 되는 경우(아래를 둘 다 만족하는 경우 사용)

 - is-a 관계 일 때("자식 클래스는 부모 클래스이다"가 성립할 때)

 - 클라이언트 입장에서 부모 클래스의 타입으로 자식 클래스를 사용 가능할 때(클라이언트 입장에서 부모 클래스와 자식 클래스의 차이점을 모를 때)

서브클래싱(subClassing)

 - 다른 클래스의 코드를 재사용할 목적으로 상속을 사용하는 경우

 - 자식 클래스와 부모 클래스의 행동이 호환되지 않기 때문에 자식 클래스의 인스턴스가 부모 클래스의 인스턴스를 대체할 수 없음

 - 구현 상속(implementation inheritance) 또는 클래스 상속(class inheritance)이라고 부르기도 함

서브타이핑(subtyping)

 - 타입 계층을 구성하기 위해 상속을 사용하는 경우

 - 자식 클래스와 부모 클래스의 행동이 호환되기 때문에 자식 클래스의 인스턴스가 부모 클래스의 인스턴스를 대체할 수 있음

 - 부모 클래스는 자식 클래스의 슈퍼타입이 되고 자식 클래스는 부모 클래스의 서브타입이 됨

 - 인터페이스 상속(interface inheritance) 이라고 부르기도 함

리스코프 치환 원칙

서브 타입은 기반 타입에 대해 대체 가능해야 한다

구현 방법과 무관하게 클라이언트의 관점에서 슈퍼타입에 대해 기대하는 모든 것이 서브타입에게도 적용되어야 한다

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

계약에 의한 설계(Design By Contract, DBC) - 클라이언트와 서버 사이의 협력을 의무와 이익으로 구성된 계약의 관점에서 표현하는 것

계약에 의한 설계의 구성 요소

 - 사전조건(precondition) : 클라이언트가 정상적으로 메서드를 실행하기 위해 만족 시켜야 하는 것

 - 사후조건(postcondition) : 메서드가 실행된 후에 서버가 클라이언트에게 보장해야 하는 것

 - 클래스 불변식(class invariant) : 메서드 실행 전과 실행 후에 인스턴스가 만족시켜야 하는 것

서브타입과 계약

 - 서브타입에 더 강력한 사전조건을 정의할 수 없다

 - 서브타입에 슈퍼타입과 같거나 더 약한 사전조건을 정의할 수 있다

 - 서브타입에 슈퍼타입과 같거나 더 강한 사후조건을 정의할 수 있다

 - 서브타입에 더 약한 사후조건을 정의할 수 없다