📝 chapter 13,14 정리

chapter13/minhyun/chapter13.md

@@ -0,0 +1,40 @@
+## 1. 알게된 점, 배운 점
+
+- 동일한 메시지에 서로 다르게 행동할 수 있는 다형적 객체를 구현하기 위해서 객체의 행동을 기반으로 타입 계층을 구성해야 한다.
+- 객체기반 → 상태와 행동을 캡슐화한 객체를 조합해서 프로그램을 구성
+    - 객체지향은 객체 기반 프로그램의 하위분류. 다만 상속과 다형성을 지원한단 점에서 차별화 됨.
+    - 객체지향은 클래스를 사용하는 프로그래밍 방식, 객체 기반은 클래스 없이 오직 객체만을 사용하는 프로그래밍 방식 (e.g. 프로토타입 기반 언어)
+- 어떤 대상이 타입으로 분류될 때 그 대상을 타입의 ‘인스턴스’ 라고 하며, 일반적으로 ‘객체’ 라고 부른다.
+- **타입의 세가지 요소**
+    1. 심볼 → 타입에 이름을 붙인 것
+    2. 내연 → 타입에 속하는 객체들이 가지는 공통 속성이나 행동
+    3. 외연 → 타입에 속하는 객체들의 집합
+- 타입이 사용되는 두가지 목적
+    1. 타입에 수행될 수 있는 유효 오퍼레이션의 집합을 정의 (e.g. ‘+’ 연산자는 숫자, 문자 객체엔 사용 가능하나 타 클래스 인스턴스에 대해선 사용불가)
+    2. 타입에 수행되는 오퍼레이션에 대해 미리 약속된 문맥을 제공 (e.g. ‘+’ 연산자가 int형, string형일때 각각 다른 문맥을 정의함)
+- 객체의 타입을 결정하는 것은 내부의 속성이 아니라 객체가 외부에 제공하는 행동이다.
+- **상속을 사용해도 되는 때**
+    1. 상속 관계가 is-a 관계를 모델링 하는가 (우선순위 2)
+    2. 클라이언트 입장에서 부모 클래스의 타입으로 자식 클래스를 사용해도 무방한가 (우선순위 1, (e.g. 펭귄은 날 수 없다.))
+        1. 클라이언트 입장에서 부모, 자식의 차이점을 몰라야 한다 → 행동 호환성
+- 일반적으로 `instanceof` 처럼 객체의 타입을 확인하는 코드는 새로운 타입을 추가할 때마다 코드 수정을 요구하기 때문에 개방-폐쇄 원칙을 위반한다.
+- 인터페이스를 클라이언트의 기대에 따라 분리함으로써 변경에 의해 영향을 제어하는 설계원칙을 ‘인터페이스 분리 원칙(ISP)’ 라고 부른다.
+- **상속을 사용하는 두가지 목적**
+    - 서브클래싱 → 다른 클래스의 코드를 재사용 할 목적(구현 상속)
+    - 서브타이핑 → 타입 계층을 구성하기 위해 상속을 사용 (인터페이스 상속)
+- 어떤 타입이 다른 타입의 서브타입이 되기 위해선 행동 호환성을 만족시켜야 하고, 행동 호환성은 부모클래스에 대한 자식 클래스의 대체 가능성을 포함한다.
+- **리스코프 치환 원칙(LSP)** → 클라이언트가 차이점을 인식하지 못한 채 기반 클래스의 인터페이스를 통해 서브 클래스를 사용할 수 있어야 한다. (= 행동 호환성 및 대체 가능성 == 서브타이핑)
+- (흥미로운 정사각형과 직사각형의 예시)
+- **클라이언트 입장에서 바라보자.**
+- **계약에 의한 설계(DBC) 의 세가지 요소**
+    1. 사전 조건 → 클라이언트가 정상적으로 메서드를 실행하기 위해 만족시켜야 하는 조건
+    2. 사후조건 → 메서드가 실행된 후 서버가 클라이언트에게 보장해야 하는 조건
+    3. 클래스 불변식 → 메서드 실행전과 실행후 인스턴스가 만족시켜야 하는 조건
+- 자식 클래스가 부모 클래스의 서브 타입이 되기 위해서는 `서브 타입에 더 강력한 사전 조건을 정의할 수 없다.`   라는 조건을 만족 시켜야 한다.
+    - 하지만 `서브타입에 슈퍼타입과 같거나 더 약한 사전 조건을 정의할 수 있다.` → 어짜피 앞에서 필터링해서 보내고 있기 때문에 약해져도 큰 문제 없음.
+- `서브타입에 슈퍼 타입과 같거나 더 강한 사후조건을 정의할 수 있다.`
+    - `서브타입에 더 약한 사후조건을 정의할 수 없다.`
+
+## 2. 궁금한 점
+
+## 3. 같이 논의해보고 싶은 내용, 공유하고 싶은 내용

chapter14/minhyun/chapter14.md

@@ -0,0 +1,9 @@
+## 1. 알게된 점, 배운 점
+
+- 유사한 기능을 구현하기 위해 유사한 협력 패턴을 사용하라 → 일관성 있는 패턴을 따른다면 시스템 이해 및 확장에 요구되는 정식적인 부담을 크게 줄일 수 있음.
+- 핸드폰 과금 시스템 코드
+- 
+
+## 2. 궁금한 점
+
+## 3. 같이 논의해보고 싶은 내용, 공유하고 싶은 내용