Merge pull request #65 from lee-ji-hoon/ezhoon

[13장_이지훈]

Author: lee-ji-hoon

src/main/kotlin/ezhoon/chapter13/README.md

@@ -0,0 +1,26 @@
+## 서브클래싱과 서브타이핑
+
+> 상속의 첫 번째 용도는 타입 계층을 구현하는 것이다. 
+> 타입 계층의 관점에서 부모 클래스는 자식 클래스의 일반화(generalization)이고 자식 클래스는 부모 클래스의 특수화(specialization)다.
+
+상속의 올바른 용도는 타입 계층을 구현하는 것이다
+
+    두 가지 후보 개념이 어떤 방식으로 사용되고 협력하는지 살펴본 후에 상속의 적용 여부를 결정해도 늦지 않는다.
+
+### 서브클래싱과 서브타이핑
+ > 언제 상속을 사용해야 하는가? 
+ > 그렇다면 어떤 조건을 만족시켜야만 타입 계층을 위해 올바르게 상속을 사용했다고 말할 수 있을까?
+ 
+- 상속 관계가 is-a 관계를 모델링하는가? 
+  - 일반적으로 "[자식 클래스]는 [부모 클래스]다"라고 말해도 이상하지 않다면 상속을 사용할 후보로 간주할 수 있다.
+- 클라이언트 입장에서 부모 클래스의 타입으로 자식 클래스를 사용해도 무방한가? 
+  - 상속 계층을 사용하는 클라이언트의 입장에서 부모 클래스와 자식 클래스의 차이점을 몰라야 한다. 이를 자식 클래스와 부모 클래스 사이의 행동 호환성이라고 부른다.
+
+### 리스코프 치환 원칙
+
+> 리스코프 치완 원칙은 "서브 타입은 그것의 기반 타입에 대해 대체 가능해야 한다"는 것으로 클라이언트가 "차이점을 인식하지 못한 채 파생 클래스의 인터페이스를 통해 서브 클래스를 사용할 수 있어야 한다"는 것이다.
+
+### 계약에 의한 설계와 서브타이핑
+- 클라이언트와 서버 사이의 협력을 의무(obligation)와 이익(benefit)으로 구성된 계약의 관점에서 표현하는 것을 계약에 의한 설계라고 부른다. 
+- 계약에 의한 설계는 클라이언트가 정상적으로 메서드를 실행하기 위해 만족시켜야 하는 사전 조건(precondition)과 메서드가 실행된 후에 서버가 클라이언트에게 보장해야 하는 사후 조건(postcondirion)과 메서드 실행 전과 실행후에 인스턴스가 만족시켜야 하는 클래스 불변식(class invariant)의 세 가지 요소로 구성된다.
+- 어떤 타입이 슈퍼 타입에서 정의한 사전 조건보다 더 약한 사전 조건을 정의하고 있다면 그 타입은 서브 타입이 될 수 있지만 더 강한 사전 조건을 정의한다면 서브 타입이 될 수 없다. 어떤 타입이 슈퍼 타입에서 정의한 사후 조건보다 더 강한 사후 조건을 정의 하더라도 그 타입은 여전히 서브 타입이지만 더 약한 사후 조건을 정의한다면 서브 타입의 조건이 깨지고 말 것이다.