Skip to content

Commit db4bcbb

Browse files
committed
[13장_양수진] 내용 정리
1 parent f6dce44 commit db4bcbb

File tree

1 file changed

+70
-0
lines changed

1 file changed

+70
-0
lines changed
+70
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,70 @@
1+
# 13 서브클래싱과 서브타이핑
2+
3+
### 상속을 사용하는 1차적인 목표는?
4+
- 코드 재사용이 아닌 타입 계층을 구현하는 것
5+
- 코드 재사용을 쉽게 할 수 있지만 부모와 자식 클래스를 강하게 겷마 -> 설계 변경 방해
6+
7+
### 동일한 메세지에 대해 서로 다르게 행동할 수 있는 다형적인 객체를 만드려면?
8+
- 객체의 행동 기반으로 타입 계층 구성하기
9+
10+
### 그럼 올바른 타입 계층이 뭔데???
11+
12+
## 01 타입
13+
- 개념 관점
14+
- 공통 특징을 공유하는 대상들의 분류
15+
- 프로그래밍 언어 관점의 타입
16+
- 비트 묶음에 의미를 부여하기 위해 정의된 제약과 규칙
17+
- 이 비트의 데이터를 문자열로 다룰까 정수로 다룰까?
18+
- 동일한 오퍼레이션을 적용할 수 있는 인스턴스들의 집합
19+
- 객체지향 관점
20+
- 개념 관점 + 프로그래밍 언어 관점
21+
- 동일한 퍼블릭 인터페이스를 제공하는 객체들은 동일한 타입으로 분류된다.
22+
- 속성보다 객체가 외부에 제공하는 행동이 중요
23+
24+
## 02 타입 계층
25+
- 타입은 다른 타입을 포함할 수 있다.
26+
- 더 일반적인 퍼블릭 인터페이스를 가지는 객체들은 더 특수한 퍼블릭 인터페이스를 가지는 객체들의 슈퍼타입.
27+
- 서브 타입의 인스턴스는 슈퍼 타입의 인스턴스로 간주될 수 있다.
28+
29+
## 03 서브클래싱과 서브타이핑
30+
31+
### 언제 상속을 사용해야 할까?
32+
- 상속 관계가 is-a 관계를 모델링하는가?
33+
- [자식클래스][부모클래스]다. 가 이상하지 않다면 상속을 사용할 후보로 간주할 수 있음
34+
- 클라이언트(상속 계층을 사용하는 입장)에서 부모 클래스와 자식 클래스의 차이를 몰라야 한다.
35+
- 그냥 자신에게 주어진 역할만 하면 객체에서 알아서 클래스에 맞는 행동을 할테니까
36+
- 행동 호환성
37+
- 인터페이스는 클라이언트가 기대하는 바에 따라 분리되어야 한다.
38+
- 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)
39+
40+
### 서브클래싱 subclassing
41+
- 다른 클래스의 코드를 재사용할 목적으로 상속을 사용하는 경우
42+
- 자식 클래스와 부모 클래스의 행동이 호환되지 않아 자식이 부모를 대체할 수 없다.
43+
- 구현 상속, 클래스 상속이라고도 한다.
44+
45+
### 서브타이핑 subtyping
46+
- 타입 계층을 구성하기 위해 상속을 사용하는 경우
47+
- 자식 클래스와 부코 클래스의 행동이 호환된다. 자식이 부모를 대체할 수 있다.
48+
- 인터페이스 상속이라고도 한다.
49+
50+
## 04 리스코프 치환 원칙
51+
- 서브타입은 그것의 기반 타입에 대해 대체 가능해야 한다.
52+
- 자식 클래스는 부모 클래스에 대한 클라이언트의 가정을 준수해야 한다.
53+
- 클라이언트의 코드를 변경하지 않고도 새로운 자식 클래스와 협력할 수 있다.
54+
55+
## 05 계약에 의한 설계와 서브타이핑
56+
- 계약에 의한 설계 Design By Contract, DBC
57+
- 클라이언트와 서버 사이 협력을 의무, 이익으로 구성된 계약의 관점에서 표현하는 것
58+
- 사전조건
59+
- 클라이언트가 메서드를 실행하기 위해 만족시켜야 하는 조건
60+
- 사후조건
61+
- 메서드 실행 후에 서버가 클라이언트에게 보장해야하는 조건
62+
- 클래스 불변식
63+
- 메서드 실행 전과 후에 인스턴스가 만족시켜야 하는 조건
64+
- 리스코프 치환 원칙 => 클라이언트와 슈퍼타입 간에 체결된 계약을 준수
65+
- 서브타입에 더 강력한 사전조건을 정의할 수 없다
66+
- 그럼 반대로 사전조건을 약화시킨다면?
67+
- 기존 협력에 영향을 미치지 않음 -> 갠찮다~
68+
- 서브타입에 더 강력한 사후조건을 정의할 수 있다.
69+
- 사후조건을 약화시키는 것은?
70+
- 원하지 않은 결과가 발생할 수 있다 -> 안된다~~

0 commit comments

Comments
 (0)