[13장_김명석] 내용 정리

Author: audxo112

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

@@ -0,0 +1,129 @@
+### 상속의 용도
+
+- **타입 계층**
+	- 부모 클래스는 일반적인 개념을 구현하고 자식 클래스는 특수한 개념을 구현
+	- 부모 클래스는 자식클래스의 **일반화**
+	- 자식 클래스는 부모클래스의 **특수화**
+- 코드 재사용
+	- 자식 클래스가 부모 클래스의 코드를 재사용할 수 있다
+
+#### 객체기반 프로그래밍
+
+- 상태와 행동을 캡슐화한 객체를 조합해서 프로그램을 구성하는 방식
+- 객체지향 프로그램도 객체기반 프로그래밍의 한 종류다
+- Visual Basic 은 객체라는 개념은 존재하지만 상속이나 다형성을 지원하지 않았다
+	- 객체기반 프로그래밍
+
+#### 객체지향 프로그래밍
+
+- **상속**과 **다형성**을 지원한다는 점에서 객체기반 프로그래밍과 차별화된다
+
+### 타입
+
+#### 개념 관점의 타입
+
+> 우리가 인지하는 세상의 사물의 종류
+
+- 타입은 **심볼, 내열, 외연** 으로 구성된다
+- 심볼
+	- 타입에 이름을 붙인 것
+- 내연
+	- 타입의 정의
+	- 타입에 속하는 객체들이 가지는 공통적인 속성이나 행동
+- 외연
+	- 타입에 속하는 객체들의 집합
+
+#### 프로그래밍 언어의 관점의 타입
+
+> 연속적인 비트에 의미와 제약을 부여하기 위해 사용
+> 비트 묶음에 의미를 부여하기 위해 정의된 제약과 규칙
+
+- 타입에 수행될 수 있는 유효한 오퍼레이션의 집합
+	- 객체의 타입에 따라 적용 가능한 연산자의 종류를 제한
+
+- 타입에 수행되는 오퍼레이션에 대해 미리 약속된 문맥을 제공
+	- 객체마다 같은 오퍼레이션에 대해 수행되는 연산이 달라진다
+
+#### 객체지향 패러다임 관점의 타입
+
+> 객체의 퍼블릭 인터페이스가 객체의 타입을 결정하며 동일한 퍼블릭 인터페이스를  제공하는 객체들은 동일한 타입으로 분류된다
+
+- 개념 관점에서 타입이란 공통의 특징을 공유하는 대상들의 분류
+- 프로그래밍 언어 관점에서 타입이란 동일한 오퍼레이션을 적용할 수 있는 인스턴스들의 집합
+	- 타입은 호출가능한 오퍼레이션의 집합을 정의
+	- 오퍼레이션의 집합 = 퍼블릭 인터페이스
+
+### 타입 계층
+
+#### 타입 사이의 포함 관계
+
+- 슈퍼타입
+	- 계층을 구성하는 관계에서 더 일반적인 타입
+	- 집합이 다른 집합의 모든 멤버를 포함한다
+- 서브타입
+	- 계층사이에서 더 특수한 타입
+	- 집합에 포함되는 인스턴스들이 더 큰 집합에 포함된다
+- 일반화
+	- 어떤 타입의 정의를 좀 더 보편적이고 추상적으로 만드는 과정
+- 특수화
+	- 어떤 타입의 정의를 좀 더 구체적이고 문맥 종속적으로 만드는 과정
+
+### 서브클래싱과 서브타이핑
+
+#### 언제 상속을 사용해야 하는가?
+
+> 상속은 타입 계층을 구현하는 것
+
+- 상속 관계가 is-a 관계를 모델링 하는가 ?
+	- 자식클래스는 부모클래스다 라고 말해도 이상하지 않다
+	- "원"은 "도형" 이다
+	- is-a 관계가 항상 옳지는 않다
+		- 펭귄은 새다
+		- 새는 날 수 있다
+		- 하지만 펭귄은 날 수 없다
+
+- 클라이언트 입장에서 부모 클래스의 타입으로 자식 클래스를 사용해도 무방
+	- 상속 계층을 사용하는 클라이언트 입장에서 부모 클래스와 자식 클래스의 차이점을 몰라야 한다
+	- **행동 호환성** 이라고 부른다
+	- 타입은 행동과 관련이 있다
+		- 개념적으로 연관성이 있더라도 행동에 연관성이 없다면 is-a 관계를 사용하면 안된다
+		- 설계가 꼭 현실의 세계를 반영할 필요는 없다
+
+- 인터페이스 분리 원칙 (ISP)
+	- 인터페이스를 클라이언트의 기대에 따라 분리하는 방식
+
+#### 서브클래싱과 서브타이핑
+
+- 서브 클래싱
+	- 다른 클래스의 코드를 재사용할 목적으로 상속을 사용하는 경우
+	- **구현 상속, 클래스 상속** 이라고도 부른다
+- 서브타이핑
+	- 타입 계층을 구성하기 위해 상속을 사용하는 경우
+	- **인터페이스 상속** 이라고도 부른다
+	- 어떤타입이 다른 타입에 서브타입이 되기 위해서는 **행동 호환성**을 만족해야한다
+
+### 리스코프 치환 원칙 (LSP)
+
+> 서브타입은 그것의 기반 타입에 대해 대체 가능해야 한다
+
+#### 클라이언트와 대체 가능성
+
+- 직사각형과 정사각형
+	- 직사각형 : 가로, 세로 길이가 다를 수 있다
+	- 정사각형 : 가로 세로 길이가 다르면 안된다
+- Vector, Stack 
+	- Vector : 임의의 Index 에 접근이 가능하다
+	- Stack : 임의의 Index에 접근해선 안된다
+- 대체 가능성을 결정하는 것은 클라이언트다
+
+### 계약에 의한 설계와 서브타이핑
+
+- 계약에 의한 설계
+	- 클라이언트와 서버 사이의 협력을 의무와 이익으로 구성된 계약관점에서 표현
+	- 서브타입이 리스코프 치환 원칙을 만족시키기 위해서는 클라이언트와 슈퍼타입 간에 체결된 **계약**을 준수 해야한다
+- 사전 조건
+	- 클라이언트가 정상적으로 메서드를 실행하기위해 만족시켜야 하는 것
+- 사후 조건
+	- 메서드가 실행된 후에 서버가 클라이언트에게 보장해야 하는 것
+- 클래스 불변식
+	- 메서드 실행 전과 실행 후에 인스턴스가 만족시켜야 하는 것