객체지향의 사실과 오해- Chapter 1 협력하는 객체의 공동체

객체에 직접적으로 대응되는 실세계의 사물을 발견할 확률은 그다지 높지 않다.

객체지향의 목표: 실세계를 모방하는 것이 아니다. 새로운 세계를 창조하는 것이다.

객체를 스스로 생각하고 스스로 결정하는 현실세계의 생명체에 비유 = 상태와 행위를 캡슐화하는 소프트웨어 객체의 자율성을 설명하는데 효과적이다.

협력 = 메시지를 주고 받으며 공동의 목표를 달성하기 위해 협력함

(연결완전성?)

커피가게의 예시

손님: 주문할 책임이 있음

캐시어: 주문 받을 책임 (바리스타한테 전달할), 커피 전달할 책임

바리스타: 커피 제조의 책임

서로 협력관계이며, 협력관계속에 자신의 책임을 다함

역할, 책임, 협력하는 다른 사람과 접촉하는 모든 곳에 존재한다.

도움을 요청(request)

-하나의 문제를 해결하기 위해 다수의 사람 혹은 역할이 필요하기 때문에 한사람의 요청이 또 다른 사람에 대한 요청을 유발하는 것이 일반적임 → 요청은 연쇄적으로 발생

(요청: 손님→ 캐시어 → 바리스타)

(응답: 바리스타 → 캐시어 → 손님 ) ( 커피전달)

1. 여러 사람이 동일한 역할을 수행할 수 있음
2. 역할 = 대체 가능성
3. 책임을 선택하는 방법은 자율적- 바리스타는 자기맘대로 제조 ( 다형성)
4. 한 사람이 동시에 여러 역할 수행가능

역할, 책임, 협력

사람- 객체, 에이전트의 요청 -메시지, 요청을 처리하는 방법- 메서드

객체지향 설계라는 예술 - 적절한 객체에게 적절한 책임을 할당하는 것에서 시작

객체의 덕목

• 협력적 - 다른 객체의 요청에 귀를 기울이고, 다른 객체에 도움을 요청할 수 있어야함

-자율적 - 자기 스스로의 원칙에 따라 어떤일을 하는 것 ( 협력에 참여하는 방법

객체는 state와 behavior를 가짐

자율성은 객체의 내부와 외부를 명확하게 구분하는 것 ( private, public 캡슐화?)

• 무엇(what)을 수행하는지는 알지만 어떻게 (how) 수행하는지는 모름

과거의 전통적인 개발 방법 - 데이터와 프로세스를 엄격하게 구분

객체지향 → 데이터에 프로세스가 들어있음, 객체의 자율성을 보장

→ 유지보수가 쉽고, 재사용이 용이한 시스템을 구축

하나의 의사소통 수단: 메시지

• sender 보내는 객체
• receiver 받는 객체

-수신된 메서드를 처리하는 방법 method

객체지향의 본질

-객체지향이란 시스템을 상호작용하는 자율적인 객체들의 공동체로 보는 것

자율적인 객체란 상태와 행위를 함께 지니며, 스스로 자기 자신을 책임지는 객체

객체는 시스템의 행위를 구현하기 위해 다른 객체와 협력함. 협력 내에서 정해진 역할을 수행하며 역할은 관련된 책임의 집합

객체는 다른 객체와 협력하기 위해 메시지를 전송하고, 메시지를 수신한 객체는 메시지를 처리하는 데 적합한 메서드를 자율적으로 선택

객체지향에 대한 오해 - 데이터 추상화를 제공하는 클래스라는 빌딩 블록에 초점이 맞춰져 있었음

클래스의 중요성이 부풀려짐

그 결과 ,객체지향의 중심에 있어야할 객체들로 관심이 멀어짐

이제 많은 사람들은 객체지향하면 클래스를 떠올림...

클래스는 매우 중요한 구성요소임은 확실하지만, 객체지향의 본질은 객체 그 자체임

코드를 담는 클래스의 관점에서 메시지를 주고받는 객체의 관점으로 사고의 중심을 전환하자!

어떤 클래스가 필요한 것이 아니라 → 어떤 객체들이 어떤 메시지를 주고받으며 협력하는 가

클래스는 객체들의 협력관계를 코드로 옮기는 도구에 불과하다.

메시지를 주고 받는 객체들의 동적인 관계 > 클래스(구현 메커니즘)

클래스의 구조와 메서드가 아니라 객체의 역할, 책임, 협력에 집중하자

객체지향은 객체를 지향하는 것이지 클래스를 지향하는 것이 아니다.