Skip to content

[6장_이동훈] #30

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 7, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
66 changes: 66 additions & 0 deletions src/main/kotlin/hoondong/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,66 @@
# 6장 메시지와 인터페이스

## 협력과 메시지

### 클라이언트-서버 모델

- 클라이언트가 서버의 서비스를 요청하는 단방향 상호작용
- 객체는 일반적으로 클라이언트와 서버의 역할을 동시에 수행

### 메서드

- 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저

### 오퍼레이션

- 퍼블릭 인터페이스에 포함된 메시지 (메서드로 보이는 부분)
- 오퍼레이션이 서버 객체에 있는 메서드를 호출하는 모양

### 시그니처

- 오퍼레이션, 파라미터 목록을 합친 것
- 반환 타입을 포함하는 언어도 존재

## 인터페이스와 설계 품질

### 좋은 인터페이스의 조건

- **최소한의 인터페이스**와 **추상적인 인터페이스**

### 디미터 법칙

- 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하는 법칙
- 객체의 내부 구조에 대한 결합으로 인해 발생하는 문제를 해결하기 위한 방법

**메시지를 보낼 수 있는 인스턴스**

- this
- 메서드의 매개변수
- this의 속성
- this 속성 중 collection 요소
- 메서드 내에서 생성된 지역 객체

### 묻지 말고 시켜라

- 객체의 상태에 관해 묻지 말고 원하는 것을 시켜야 한다는 법칙
- 메시지 수신자의 상태를 기반으로 결정을 내리면 안됨

### 의도를 드러내는 인터페이스

- 이름부터 메서드의 작업을 잘 나타내도록 지어야 함
- 본인의 구현 방식에 대해 나타낼 필요가 없음
- **어떻게 수행하느냐** 보다 **무엇을 하느냐**에 초점을 맞춰야 함

### 명령-쿼리 분리 원칙

- 위의 규칙들을 지킨다고 모두 긍정적인 결과가 나오는 것이 아님
- 책임의 주체가 변하기 때문에 처음 설계와 다른 결과가 나올 수 있음
- 필요에 따라 물어야 하는 경우가 발생함

**루틴** : 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈

**프로시저** : 정해진 절차에 따라 내부의 상태를 변경하는 루틴 (반환값 X) → **명령**

**함수** : 정해진 절차에 따라 필요한 값을 계산해서 반환하는 루틴 (부수효과 X) → **쿼리**

⇒ 예측 가능한 협력을 만들기 위해 명령과 쿼리를 분리하여 사용