|
| 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