객체지향의 사실과 오해 - Chapter3, Chapter4

이번은 객체지향의 사실과 오해 스터디 2번 째 날이다.

Chapter3, 4는 조금 어려운 내용으로 구성되있어 생각보다 읽는데 어려움을 겪었다.

특히 Chapter4는 단어들이 어려워 이해하는데 시간이 조금 많이 걸렸다. 한 번 정리해보도록 하겠다.

 

Chapter 3. 타입과 추상화

 

1. 추상화 

 

"어떤 세부 사항, 구조를 명확하게 이해하기위해 특정 절차나 물체를 의도적으로 생략하거나 감춤으로 복잡도 극복"

 

추상화의 방법 : 공통점을 취하고 차이점을 버리는 일반화. 불필요한 부분을 제거.

 

그렇다면 왜 추상화와 객체가 관련있을까?

이러한 추상화를 통해 객체를 구현하기 때문이다.

어떻게 구현을 할까?

개념(공통점을 묶기위한 그릇)에 따라서 분류(여러 그룹으로 나눔)하고 인스턴스(그룹의 일원)를 생성한다.

 

- 개념의 관점

1. 심볼(symbol) : 개념을 가리키는 명칭 또는 이름

2. 내연(intension) : 개념의 완전한 정의. 이것으로 객체가 개념에 속하는지 여부 확인

3. 외연(extension) : 개념에 속하는 모든 객체의 집합

 

 

2. 타입

"타입 = 개념"

 

- 데이터 타입

컴퓨터는 "1"과 "0"으로 동작한다. 그러나 우리는 숫자인지 문자인지 구별하고 싶어서 타입 시스템을 도입했다.

이러한 데이터 타입은 연산자의 종류가 아니라 어떤 연산자를 적용할 수 있느냐가 중요하다.

그러니까 타입을 나누는 기준은 데이터 타입이 어떤 행동을 할 수 있느냐이다. 

그리고 데이터 타입이라는 객체가 무엇으로 이루어져 있는지는 알 필요없다. 행동을 할 수 있느냐가 중요하다.

예를 들어 문자는 더하기가 불가능하다. 정수는 가능하다. 이렇게 더한다라는 동작이 가능한지 여부 결정적이다.

이렇게 행동과 캡슐화를 기준으로 데이터 타입을 결정할 수 있다.

 

- 객체

객체는 데이터가 아니다. 왜냐면 데이터는 행동을 할 수  없기 때문이다.

행동을 기준으로 객체는 생성되어져야한다. 객체가 다른 데이터를 가지고 있어도 같은 행동을 하면 같은 타입이다.

이렇게 행동을 기준으로 타입을 나누는 객체는 "다형성"이라는 특징을 가진다.

일단 동일한 책임은 동일한 메세지 수신을 의미한다. 수신은 똑같이하고 다른 방식으로 응답하는 것을 다형성이라한다.

그리고 수신은 똑같이 받아들이는 특징을 "캡슐화"라고 한다.

내부적으로 어떤 방식으로 수신받은 메세지를 처리 할 지는 아무도 모른다.

 

"객체 결정은 행동!!!데이터는 단지 행동을 따를 뿐"

 

 

- 일반화/특수화

특수한 타입(트럼프 사람)은 일반한 타입(트럼프)보다 훨씬 많은 행동을 가지지만 더 적은 크기의 외연 집합을 가진다.

 

- 동적 모델과 정적 모델

타입은 동적인 객체를 정적으로 보기위해서 필요하다.

예를 들면 앨리스의 키는 음식들을 먹을 때마다 상태가 변한다. 그러나 앨리스는 변하지 않는다. 그래서 키는 동적으로 변하지만 앨리스라는 객체중심으로 보고 키는 임의의 값을 가질 것이라 예상하고 설계한다.

 

 

 

Chapter 4. 역할, 책임, 협력

구매해라 -> 사람 -> 들고가자 -> 자동차 

 

1. 협력(요청하고 응답하며 협력하는 사람들)

 

다수의 요청과 응답으로 구성. 

위의 그림처럼 요청을 주면 그 요청을 받을 수 있는 객체에게 전달된다. 이유는 요청에 대해서 적절한 방식으로 응답하는데 필요한 지식과 행동 방식을 가지고 있기 때문이다.

 

 

2. 책임

요청에 적절한 행동을 하거나 대답을 해줄 의무가 있는 것.

 

객체의 책임은 "무엇을 알고 있는가" + "무엇을 할 수 있는가"로 이루어져 있다.

설계를 할 경우 어떤 객체가 어떤 책임을 가지고 어떤 방식으로 서로 협력해야 하는지에 대한 개요를 아는 것.

더 중요한 것은 특정 메세지를 수신하고 송신하는 것을 결정하는 일이다.

 

3. 역할

책임의 집합

 

역할은 재사용이 가능하고 유연한 객체지향 설계를 낳는 중요한 요소.

만약 재판관의 역할을 다른 사람이 할 수 있을까? 수신 메세지 방식만 동일하면 역할을 대체 할 수 있다.

역할은 일반화이며 객체의 타입은 특수화이다. 예를 들면 인터페이스는 역할, 구현체는 특수화이다.

 

4. 객체의 설계

협력을 설계 -> 행동을 결정 -> 수행 시 필요한 데이터 결정 -> 클래스 구현 방법결정.

 

- 책임 - 주도 설계(Responsibility-Driven Design)

 

책임을 파악하고 책임을 더 작은 책임으로 나누고 책임을 수행 할 수 있는 객체 또는 역할을 찾아 책임을 할당.

 

- 디자인 패턴(Design Pattern)

 

공통적으로 사용할 수 있는 역할, 책임, 협력의 템플릿. 

 

- 테스트-주도 개발(Test-Driven Development)

 

책임 주도 설계방식을 더욱 안전하게 사용할 수 있도록 만든 테스트 기반의 코딩.

 

 

이렇게 객체지향의 사실과 오해를 반 정도 읽었다. 책을 읽고 토론하고 생각을 블로그에 정리하면서 제일 많이 느낀 점은 "데이터 중심이 아닌 행동 중심의 객체 설계"이다. 현재 Spring도 같이 병행하고 있어서 이것을 인터페이스와 구현체에 대입해서 직접 느끼니 이해가 더 잘된다. 다음 5,6장이 기대된다.