[13장_양수진]

src/main/kotlin/yangsooplus/ch13/README.md

@@ -0,0 +1,70 @@
+# 13 서브클래싱과 서브타이핑
+
+### 상속을 사용하는 1차적인 목표는?
+- 코드 재사용이 아닌 타입 계층을 구현하는 것
+- 코드 재사용을 쉽게 할 수 있지만 부모와 자식 클래스를 강하게 겷마 -> 설계 변경 방해 
+
+### 동일한 메세지에 대해 서로 다르게 행동할 수 있는 다형적인 객체를 만드려면?
+- 객체의 행동 기반으로 타입 계층 구성하기
+
+### 그럼 올바른 타입 계층이 뭔데???
+
+## 01 타입
+- 개념 관점
+  - 공통 특징을 공유하는 대상들의 분류
+- 프로그래밍 언어 관점의 타입
+  - 비트 묶음에 의미를 부여하기 위해 정의된 제약과 규칙
+    - 이 비트의 데이터를 문자열로 다룰까 정수로 다룰까?
+  - 동일한 오퍼레이션을 적용할 수 있는 인스턴스들의 집합
+- 객체지향 관점
+  - 개념 관점 + 프로그래밍 언어 관점
+  - 동일한 퍼블릭 인터페이스를 제공하는 객체들은 동일한 타입으로 분류된다.
+    - 속성보다 객체가 외부에 제공하는 행동이 중요
+
+## 02 타입 계층
+- 타입은 다른 타입을 포함할 수 있다.
+- 더 일반적인 퍼블릭 인터페이스를 가지는 객체들은 더 특수한 퍼블릭 인터페이스를 가지는 객체들의 슈퍼타입.
+- 서브 타입의 인스턴스는 슈퍼 타입의 인스턴스로 간주될 수 있다.
+
+## 03 서브클래싱과 서브타이핑
+
+### 언제 상속을 사용해야 할까?
+- 상속 관계가 is-a 관계를 모델링하는가?
+  - [자식클래스]는 [부모클래스]다. 가 이상하지 않다면 상속을 사용할 후보로 간주할 수 있음
+- 클라이언트(상속 계층을 사용하는 입장)에서 부모 클래스와 자식 클래스의 차이를 몰라야 한다.
+  - 그냥 자신에게 주어진 역할만 하면 객체에서 알아서 클래스에 맞는 행동을 할테니까
+  - 행동 호환성
+  - 인터페이스는 클라이언트가  기대하는 바에 따라 분리되어야 한다. 
+    - 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)
+
+### 서브클래싱 subclassing
+ - 다른 클래스의 코드를 재사용할 목적으로 상속을 사용하는 경우
+ - 자식 클래스와 부모 클래스의 행동이 호환되지 않아 자식이 부모를 대체할 수 없다.
+ - 구현 상속, 클래스 상속이라고도 한다.
+
+### 서브타이핑 subtyping
+- 타입 계층을 구성하기 위해 상속을 사용하는 경우
+- 자식 클래스와 부코 클래스의 행동이 호환된다. 자식이 부모를 대체할 수 있다.
+- 인터페이스 상속이라고도 한다.
+
+## 04 리스코프 치환 원칙
+- 서브타입은 그것의 기반 타입에 대해 대체 가능해야 한다.
+  - 자식 클래스는 부모 클래스에 대한 클라이언트의 가정을 준수해야 한다.
+- 클라이언트의 코드를 변경하지 않고도 새로운 자식 클래스와 협력할 수 있다.
+
+## 05 계약에 의한 설계와 서브타이핑
+- 계약에 의한 설계 Design By Contract, DBC
+  - 클라이언트와 서버 사이 협력을 의무, 이익으로 구성된 계약의 관점에서 표현하는 것
+  - 사전조건
+    - 클라이언트가 메서드를 실행하기 위해 만족시켜야 하는 조건
+  - 사후조건
+    - 메서드 실행 후에 서버가 클라이언트에게 보장해야하는 조건
+  - 클래스 불변식
+    - 메서드 실행 전과 후에 인스턴스가 만족시켜야 하는 조건
+- 리스코프 치환 원칙 => 클라이언트와 슈퍼타입 간에 체결된 계약을 준수
+- 서브타입에 더 강력한 사전조건을 정의할 수 없다
+  - 그럼 반대로 사전조건을 약화시킨다면?
+    - 기존 협력에 영향을 미치지 않음 -> 갠찮다~
+- 서브타입에 더 강력한 사후조건을 정의할 수 있다.
+  - 사후조건을 약화시키는 것은?
+    - 원하지 않은 결과가 발생할 수 있다 -> 안된다~~