: 핵심 키워드는 메시지. 객체에게 메시지를 날려 무언가를 처리하기를 요구한다.
객체지향적 관점이란?
: 시스템을 객체들이 모여있는 덩어리로 시스템을 바라보는 관점.
- 함수형에서는 시스템을 함수의 집합체로 바라보고, 절차지향에서는 시스템을 프로세스와 데이터의 집합체로 바라본다.
- 객체지향에서는 객체들끼리 모여 시스템을 만들기 때문에, 객체는 다른 객체와 연결되어있다. (클래스 관점에서의 의존과는 다르다.)
책임-주도 설계: 역할, 책임, 협력
: 협력을 위한 문맥(애플리케이션 기능) 안에서 책임을 수행할 역할(객체) (추상화) 선택
- 객체에 할당할 책임이 설계를 주도하는 원칙
- 과정: 책임과 메시지를 선택(정의)하고, 책임에 적합한 역할(객체)를 찾는다. 메시지를 받은 객체는 그 메시지를 처리할 메서드를 구현하고, 메서드가 필요한 상태를 정의한다.
- 이 순서대로라면, 설계에서 메서드와 상태를 먼저 결정해버리면 안된다.
책임 -> 메시지 -> 역할(객체) -> 메서드 -> 상태
1. 협력
: 한 객체가 다른 객체에게 메시지를 전송해 무언가를 요청하고 응답을 받는다.
- 객체간 협력을 설계하는 법: “이 시스템에 어떤 객체들이 필요하고, 어떻게 협력해야한다.” 를 먼저 생각한다.
메시지와 메서드의 차이점
- 메서드는 메시지를 처리하는 하나의 방법이다.
- e.g) 다형성: 한 메시지에 대해 각각의 다른 객체들은 다르게 행동하는 것(메서드)
- 템플릿 메소드 패턴: 어떤 메소드가 수행될지는 메시지를 받은 객체에 의해 런타임에 결정된다.
객체간 협력의 두가지 측면
- 컴파일 측면: 시스템의 컴파일타임 측면 (단순히 클래스 사이에서의 관계)
- 코드 설계 중심: 사용자에게 어떠한 가치를 제공할 수 있는지를 고민
- 첫번째 클라이언트 중심: 실제 사용자 중심 설계이다. 사실상 코딩의 첫번째 목적이기 때문에 일단 먼저 중요하긴하다.
- 런타임 측면: 런타임에 객체들이 어떻게 협력할지에 대한 측면. (객체지향적 관점)
- 기능 설계 중심: 개발자가 변경하기 쉬운 품질 좋은 코드
- 두번째 클라이언트 중심: (동료)개발자 중심 설계이다. 이게 충족되더라도, 첫번째 클라이언트를 만족시키지 못하면 안된다.
2. 책임
: 받은 메시지를 수행하는 것. 메시지를 수행하기 위해서는 수행하는 메소드가 있어야 한다. 메소드에 필요한 상태도 있다.
- 메소드: 메시지를 수행 할 수 있다.
- 상태: 메소드를 수행하기 위한 상태를 들고 있다.
3. 역할
: 책임들의 집합. 책임들로 추상화된 객체
정리: 객체지향의 핵심
- 클래스보다 객체가 중요하다.
- 객체보다 객체가 담는 메시지가 중요하다.
- 상태보다 행동이 중요하다.
- 메시지와 메서드이 분리는 유연한 설계의 기반이다.
- 애플리케이션은 정적인 클래스로 구성되긴 하지만, 메시지만을 통해서도 정의가 될 수 있다.
Reference)
객체지향의 사실과 오해 조영호님 강의